Feature Request: Granular Agent Tool Permission Controls

[l4b4r4b4b4]

Feature Request: Granular Agent Tool Permission Controls

Summary

Currently, Zed Editor provides an all-or-nothing approach to agent tool permissions where users can either:

• Allow/deny each tool call individually
• Use 'Allow always' for all tool calls globally

Feature Request

I would like to request more granular control over the 'Always Allow' functionality, specifically:

1. Command-Specific Permissions

• Allow specific commands to always be permitted (e.g., always allow ls, cat, grep)
• Maintain individual approval for other commands

2. Tool-Specific Permissions

• Allow specific tools to always be permitted (e.g., always allow read_file, write_file)
• Maintain individual approval for other tools

3. Pattern-Based Permissions

• Allow command patterns (e.g., always allow ping *, npm install *)
• Support for safe, read-only commands vs. potentially destructive operations

4. Always Deny Rules

• Implement the same granular control for 'Always Deny' functionality
• Block specific commands/tools permanently without prompting

Use Cases

Developer Workflow

• Always allow safe diagnostic commands: ls, cat, grep, find
• Always allow read-only file operations: read_file
• Still require approval for: rm, write_file, terminal with destructive commands

Security-Conscious Users

• Always deny potentially dangerous commands: rm -rf, sudo, curl to external sites
• Always allow safe inspection tools: head, tail, wc

Productivity Enhancement

• Reduce interruptions for commonly used, safe operations
• Maintain security for potentially risky operations

Suggested Implementation

UI Enhancements

1. Permission Rules Panel: A dedicated settings section for managing permission rules
2. Rule Types:
   • Command patterns (regex support)
   • Specific tool names
   • Combined tool + command patterns
3. Rule Actions: Always Allow, Always Deny, Ask Each Time (default)

Configuration File

{
  "agent_permissions": {
    "rules": [
      {
        "pattern": "ping *",
        "type": "command",
        "action": "always_allow"
      },
      {
        "pattern": "read_file",
        "type": "tool",
        "action": "always_allow"
      },
      {
        "pattern": "rm -rf *",
        "type": "command",
        "action": "always_deny"
      }
    ]
  }
}

Benefits

1. Enhanced Security: Fine-grained control over what agents can do
2. Improved Productivity: Fewer interruptions for trusted operations
3. Better User Experience: Customizable to individual workflow needs
4. Maintains Safety: Dangerous operations still require explicit approval

Related Issues

This builds upon the existing agent tool permission system and would enhance issues like:

• Agent: Support timeout for terminal tool calls #32157 (Agent: Support timeout for terminal tool calls)
• General agent tool usage and security concerns

Environment

• OS: Cross-platform request
• Zed Version: Latest
• Use Case: Developer productivity and security enhancement

Would love to hear thoughts from the community and maintainers on this feature request!

[akaihola]

Duplicate of #30313?

[notpeter]

There is definitely room for improvement/enhancement for how tool permissions are handled. I'm not sure whether simple text/regex/glob based rules are up to the task. The requirement for users to manually compose/test/modify these statements to control this feature raises some pretty clear UX concerns.

There are also very real concerns with how to match pipelines, chained commands, file redirections, variable interpolation, shell script execution, etc. And for that I think we would need to actually parse all the commands (and support multiple shell dialects).

I'm not sure the best path forward but would love to capture some of the prior art used by other editors.

Thanks for reporting.

[akaihola]

would love to capture some of the prior art used by other editors

I've been using Roo Code a fair bit. Here's an example of how this works there. I asked Roo Code to "check the uv.lock file":

I can click on the blue "Approve" button to approve the action this one time. If I open the "Auto-approve" section, I get this:

Here I can select the "Read" action, and file reading will be auto-approved from then on.

If I had asked Roo to run a shell command, I could select the Settings link and be taken to the details of the Execute action:

These are, in my experience, just prefix substring patterns, so all your concerns about pipelines, chained commands etc. are very valid. I haven't run into such cases yet, but I can imagine possible disasters.

[mcary]

I haven't used other "art" that addresses this problem well, but I would really like to have a solution in Zed.

Would it be possible to model a command as an array of strings (as passed to execve) rather than a string of shell commands (as passed to sh -c)? It might side-step issues around parsing pipes and other shell metacharacters that could allow (for example) commands starting with cat and thereby accidentally allowing cat non-existent || rm -rf /.

This may seem like a major constraint, but if the agent is going to have the command auto-approved, it could potentially combine commands itself (if command A files, run command B).

Also, a user could write a wrapper script to perform common operations and supporting a small number of parameters, encapsulating things like cd <dir> && git commit -am '<msg>' as ./commit-in.sh <dir> <msg>.

[mcary]

Alternatively, matching the full string with a small collection of regex-like macros might be adequate. For example, if the user is asked for permission to allow cd other-project && git commit -am 'do the thing', they could be given an auto-approve section (as with Roo) and allowed to select parameters which should be replaced by one of a short list of provided patterns that match common shell strings: one for a file path, one for a file path segment, one for a shell word, one for a single-quoted string, etc. That UI would allow the user to convey that I want to generalize my granting of permission to anything that entirely matches cd {file-path} && git commit -am {single-quoted-string}. Rather than expecting the user to enter this syntax into a free-form form field, the UI could allow them to select a substring of the command and offer the regex-like macros that could match it in a drop-down so that the user can select the best macro. These kinds of "training wheels" could reduce potential user error associated with writing regexes from scratch.

[mcary]

One more idea that could work for more than just shell scripts: Instead of giving find-grain permissions for a particular category of tool (such as the ones that run shell commands), how about making it really easy for a user to create a very narrow custom tool that is implemented in terms of the original tool the model tried to use, and then always grant access to that specialized tool? For example, if the model tries to use the command tool to run cd <dir> && git commit -am '<msg>', Zed could allow the user to create a special-purpose tool for that job, a commit-in-other-dir tool. The user can then say what parameters the tool accepts and how they are to be passed to the original tool. For string parameters, that mapping might be defined by a simple templating language such as handlebars. So if I create a special-purpose tool that should accept a repo directory and commit message, then I'd ask the special-purpose tool to call the orignal tool with a command of `cd {{repo_directory.shell_escape}} && git commit -am {{commit_message.shell_escape}}' or something like that. (As with other options, I'd hope for Zed to offer the user a panel or wizard to easily accomplish that task.)

Although the example is again with shell commands, the general idea could be applied to tools that do other things -- making HTTP requests, creating objects in a database, etc. The idea more decoupled from the specific shell command use-case.

(If the user could open the specification for the parameter mapping in a Zed buffer, specified as markdown or yaml, then they could get an agent's help in refining and maintaining it.)

[JohnPreston]

This is proving to be more necessary than anything to have in Zed.
Even with rules explicitly saying not to use delete_path tool, and what to do instead, the LLM and the agent still allow for these to use, wasting away code and tokens in re-writing files that already were there and so on. It's incredibly infuriating.

So both the rules need to be followed and passed to the LLM and we need tool level ACL.

[mcary]

I agree about the necessity of this. I'm moving my current project into Claude's CLI for its finer-grained command ACL support.

Perhaps it is a natural progression of automating the agent-centered workflow of this project, moving from an interactive environment (the Zed IDE) where I can iterate quickly to an environment where the agent can iterate with less supervision. But I would prefer to keep it in Zed for longer.

[dilchenko]

CLine simply added another section into each MCP configuration, called autoApprove:

    "github.com/modelcontextprotocol/servers/tree/main/src/memory": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-memory"
      ],
      "disabled": false,
      "autoApprove": [
        "create_entities",
        "create_relations",
        "add_observations",
        "read_graph",
        "open_nodes"
      ]
    }

Simply allowing to specify auto-approved tools in the config would be a massive improvemnet. Even if this is not exposed in the UI, i.e. there is no button to click that allows certain action for a certain tool.

[nikaro]

For inspiration, opencode configuration example:

  "permission": {
    "bash": {
      "find *": "allow",
      "git diff *": "allow",
      "git log *": "allow",
      "git status *": "allow",
      "git show *": "allow",
      "grep *": "allow",
      "ls *": "allow",
      "pwd": "allow",
      "which *": "allow",
      "*": "ask",
    },
    "edit": "ask",
    "glob": "allow",
    "grep": "allow",
    "list": "allow",
    "lsp": "allow",
    "patch": "ask",
    "question": "allow",
    "read": {
      "*": "allow",
      "*.env": "deny",
      "*.env.*": "deny",
      "*.envrc": "deny",
      "*.envrc.*": "deny",
      "*.env.example": "allow",
    },
    "skill": "allow",
    "task": "ask",
    "todoread": "allow",
    "todowrite": "allow",
    "webfetch": "ask",
    "write": "ask",
    // mcp
    "context7_*": "ask",
    "exa_*": "ask",
    "pw_*": "ask",
  },

[JosephTLyons]

Hey @l4b4r4b4b4 - stable v0.221.4 adds more granular permissions via:

• Granular Tool Permission Buttons #46284

I think this covers most of what was mentioned here, but feel free to open another discussion if there are other things you want us to consider here.

[JosephTLyons]

Sorry all, I made a mistake here. it has landed in stable, but it is behind a staff feature flag for a tiny bit longer, so expect this to go live in the next week or so. We had some UI/UX to improve.

[l4b4r4b4b4]

Hey @l4b4r4b4b4 - stable v0.221.4 adds more granular permissions via:

* [Granular Tool Permission Buttons #46284](https://github.com/zed-industries/zed/pull/46284)

I think this covers most of what was mentioned here, but feel free to open another discussion if there are other things you want us to consider here.

yeah just saw the original idea of this feature request issue on pattern matching landing in nixos HM module 🥳 🥳 🥳

Awesome work!!!

[panggihsieh]

Title

Feature Request: Add a Dedicated "Permissions" Tab in Agent Settings for Structured UI-Based Control

Description / Rationale

1. Proposed Feature

Add a dedicated "Permissions" tab under Zed's Agent Settings (agent: open settings).
This tab should provide a visual, structured UI (matrix/toggles) for managing tool permissions—such as edit_file, terminal, and mcpServers—allowing users to configure fallback defaults (allow, confirm, deny) and whitelist patterns without manually editing regex in settings.json.

2. Why This Is Needed

• Simplifies Configuration: Writing complex regex patterns in tool_permissions JSON manually introduces a steep learning curve and risk of syntax errors.
• Improves Safety & Clarity: A structured UI prevents accidental global auto-approvals (YOLO mode) and makes security boundaries (e.g., always_confirm vs always_deny) visually explicit.
• Reduces Context Switching: Users can quickly adjust permissions on the fly via GUI without diving into raw config files during fast-paced agentic coding sessions.

3. Key UI Elements Suggested

• Per-Tool Action Toggles: Simple Radio/Toggle switches for Always Allow, Prompt / Confirm, and Always Deny for each tool.
• Pattern List Builder: A visual list interface to easily add or remove trusted command prefixes (e.g., npm test, git status) and protected path patterns.
• Sync with JSON: GUI actions should seamlessly serialize back into ~/.config/zed/settings.json under agent.tool_permissions to maintain git-friendly configuration.