6502012bc7ac2d3b394f59aececcc4ed0bc23ef4
5
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Eric Holk
|
3554944a72 |
Make terminal permission pattern suggestions subcommand-specific (#49148)
Previously, clicking "Always allow for `cargo` commands" after running `cargo build --release` would also silently permit `cargo run` (arbitrary code execution), `cargo publish`, and any other cargo subcommand. This was overly broad and did not match user intent. Now the extracted pattern includes the subcommand when present, so the button reads "Always allow for `cargo build` commands" and the pattern `^cargo\s+build\b` only matches `cargo build` invocations — not `cargo test`, `cargo run`, etc. ### How it works - The second token is included in the pattern when it looks like a subcommand (alphanumeric, hyphens, underscores, no leading `-`). - When the second token is a flag (e.g. `ls -la`), only the command name is used — the user sees "Always allow for `ls` commands". - Single-word commands and path-like commands behave the same as before. ### Examples | Command | Pattern | Button label | |---|---|---| | `cargo build --release` | `^cargo\s+build\b` | Always for `cargo build` commands | | `cargo test -p search` | `^cargo\s+test\b` | Always for `cargo test` commands | | `npm install` | `^npm\s+install\b` | Always for `npm install` commands | | `ls -la` | `^ls\b` | Always for `ls` commands | | `ls` | `^ls\b` | Always for `ls` commands | | `./script.sh` | *(rejected)* | *(no pattern button)* | Release Notes: - Agent: "Always allow" suggestions for terminal commands are now subcommand-specific (e.g. "Always allow for `cargo build` commands" instead of "Always allow for `cargo` commands"). |
||
|
Richard Feldman
|
fae1f46943 |
Extract shell_command_parser into shared crate (#48660)
Move shell command parsing logic (`extract_commands` and supporting code) from the agent crate into a new `shell_command_parser` crate so it can be reused by `agent_servers` for ACP permission checking. Release Notes: - N/A |
||
|
Richard Feldman
|
19b01d136f |
Harden tool authorization: sensitive settings, deferred ops, copy/move patterns (#48641)
This PR hardens the authorization flow for all file and directory tools. ## Sensitive settings protection All file/directory tools (copy, move, create_directory, delete, save, edit, streaming_edit) now detect and protect sensitive settings paths: - Paths inside `.zed/` directories (local settings) - Paths inside the global config directory (`~/.config/zed/` or equivalent) Even when the global default is `allow`, modifications to these paths require explicit confirmation. The authorization dialog title is annotated with "(local settings)" or "(settings)" to inform the user. `sensitive_settings_kind` walks up ancestor directories to handle paths where intermediate subdirectories don't exist yet (e.g. `~/.config/zed/new_subdir/evil.json`). ## Deferred filesystem operations Copy, move, create_directory, and delete tools now defer all project/filesystem operations until after the user authorizes the action. Previously, some tools began resolving project paths or traversing directories before authorization. ## streaming_edit_file permissions `streaming_edit_file` now shares `edit_file`'s tool name for permission checks, ensuring consistent permission rules between the two edit tool variants. The duplicated authorization logic is replaced by a shared `authorize_file_edit` function. ## Copy/move pattern extraction Copy and move tools now include both source and destination paths in their permission context (`input_value`). The always-allow pattern is extracted from the common parent directory of both paths, ensuring the pattern covers future checks against both. ## Save tool improvements - Authorization title now shows only the paths that need confirmation, not all paths - Title is annotated with "(local settings)" or "(settings)" for sensitive paths Release Notes: - File and directory tool operations now require confirmation before modifying sensitive settings paths. |
||
|
Richard FeldmanandZed Zippy
|
6ff5dec7b7 |
Fix shell injection vulnerability in terminal tool permissions (#47807)
<img width="1110" height="280" alt="Screenshot 2026-01-28 at 3 35 52 PM" src="https://github.com/user-attachments/assets/4d467e2c-2e7b-4ec7-bc87-6f0df8e667f0" /> <img width="1094" height="411" alt="Screenshot 2026-01-28 at 3 40 54 PM" src="https://github.com/user-attachments/assets/f559df93-e72e-4457-ba1b-f7d6239f3285" /> Previously, if a user configured `^ls` as an always-allow pattern, an attacker could craft a command like `ls && rm -rf /` which would be auto-approved because the regex only matched the beginning of the command string. Now the command is parsed into individual sub-commands (`ls`, `rm -rf /`) and EACH sub-command must match an allow pattern for auto-approval. This prevents shell injection attacks using operators like: - `&&` and `||` (boolean operators) - `;` and `&` (sequential/background execution) - `|` (pipes) - Newlines - Command substitution (`$()` and backticks) - Process substitution (`<()` and `>()`) ## Matching Logic - **always_deny**: if ANY sub-command matches, deny the entire command - **always_confirm**: if ANY sub-command matches, require confirmation (unless always_deny matched, in which case deny) - **always_allow**: ALL sub-commands must match for auto-approval (unless always_confirm or always_deny matched, in which case defer to those) - If parsing fails, or if the shell is unsupported, then always_allow is disabled for this command As usual, `always_allow_tool_actions` supercedes all of these. If it is `true`, then we always allow all tool calls, no questions asked. ## Shell Compatibility The shell parser only supports POSIX-like command chaining syntax (`&&`, `||`, `;`, `|`). **Supported shells:** Posix (sh, bash, dash, zsh), Fish 3.0+, PowerShell 7+/Pwsh, Cmd, Xonsh, Csh, Tcsh **Unsupported shells:** Nushell (uses `and`/`or` keywords), Elvish (uses `and`/`or` keywords), Rc (Plan 9 shell - no `&&`/`||` operators) For unsupported shells: - The "Always allow" UI options are hidden for the terminal tool - If the user has `always_allow` patterns configured in settings, they will see a `Deny` with an explanatory error message (No release notes because granular tool permissions are behind a feature flag.) Release Notes: - N/A --------- Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com> |
||
|
|
dd4699dc72 |
Granular Tool Permission Buttons (#46284)
Adds buttons for confirming (and optionally persisting) granular permissions on tool calls: <img width="688" height="302" alt="Screenshot 2026-01-14 at 1 58 40 PM" src="https://github.com/user-attachments/assets/3228cc39-efd5-4a73-989f-ddb28969847f" /> <img width="690" height="282" alt="Screenshot 2026-01-14 at 1 58 31 PM" src="https://github.com/user-attachments/assets/8367a888-5728-4877-a502-1ff20ac929ec" /> ## Features ### Tool Permission Settings - **Per-tool rules** in `agent.tool_permissions.tools.<tool_name>`: - `default_mode`: `"allow"`, `"deny"`, or `"confirm"` (default) - `always_allow`: Array of regex patterns to auto-approve - `always_deny`: Array of regex patterns to block - `always_confirm`: Array of regex patterns requiring confirmation - **Supported tools**: `terminal`, `edit_file`, `delete_path`, `move_path`, `create_directory`, `save_file`, `copy_path`, `fetch`, `web_search` - **MCP tool support**: Third-party tools from context servers with `mcp:<server>:<tool>` naming ### Smart Permission Buttons When a tool requires confirmation, the dialog shows contextual buttons: - **"Always allow \`<tool>\`"** - Sets `default_mode = "allow"` for the tool - **"Always allow \`<pattern>\`"** - Adds a pattern to `always_allow`: - Terminal: Command name (e.g., `cargo`, `npm`, `git`) - File tools: Parent directory path - URL tools: Domain name - **"Allow"** / **"Deny"** - One-time decision ### Pattern Extraction Automatically extracts meaningful patterns from tool inputs: - Terminal commands → `^cargo\s`, `^npm\s`, etc. - File paths → `^/Users/alice/project/src/` - URLs → `^https?://github\.com` ### Invalid Pattern Handling - Malformed regex patterns are detected at settings load time - Tools with invalid patterns show an error and block execution - Clear error messages identify which pattern failed ## Changes ### New Files - `crates/agent/src/tool_permissions.rs` - Permission evaluation logic - `crates/agent/src/pattern_extraction.rs` - Pattern extraction functions ### Modified Files - `crates/agent_settings/src/agent_settings.rs` - `ToolPermissions`, `ToolRules` structs - `crates/settings/src/settings_content/agent.rs` - Settings schema and serialization - `crates/settings/src/settings_file.rs` - Helper methods for modifying settings - `crates/agent/src/thread.rs` - `authorize_with_context()`, `authorize_third_party_tool()` methods - `crates/agent/src/tools/*.rs` - Updated all granular tools to use permission system - `crates/agent/src/tools/context_server_registry.rs` - MCP tool authorization - `crates/agent_ui/src/acp/thread_view.rs` - Permission button UI, removed Keep/Reject buttons ## Example Configuration ```json { "agent": { "tool_permissions": { "tools": { "terminal": { "default_mode": "confirm", "always_allow": ["^cargo\\s", "^npm\\s", "^git\\s"], "always_deny": ["^rm\\s+-rf", "^sudo\\s"] }, "edit_file": { "default_mode": "allow", "always_deny": ["^\\.env", "^/etc/"] }, "mcp:filesystem:write_file": { "default_mode": "confirm" } } } } } ``` Release Notes: - You can now set per-tool permissions when confirming/denying tool use --------- Co-authored-by: Amp <amp@ampcode.com> Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com> Co-authored-by: Michael Benfield <mbenfield@zed.dev> |