AI: "Always allow" tool button should only apply to the current tool, not all tools

[and-reas-se]

Summary

A button that looks like it's meant to always allow a specific tool puts "always_allow_tool_actions": true in your config, allowing every tool to be used without confirmation.

Description

Steps to trigger the problem:

1. Install the "Context7 MCP Server" extension.
2. Delete the agent section in your zed config if you have one and save the config.
3. Ask Claude 3.7 Sonnet from the Zed provider to look up the id of something using the resolve-library-id tool added by the extension. If it makes a difference I observe the behavior during the pro trial period.
4. When asked if you want to allow the tool, press what appears to be a button to always allow this tool, since this is a rather safe tool that shouldn't need confirmation.
5. Ask it to use another, unrelated tool that should require user confirmation, like terminal.

Actual Behavior: It uses the other tool without asking for confirmation.

Expected Behavior: It should ask for confirmation before running the other tool, since you have not always allowed the other tool, only the resolve-library-id tool.

Additional details

It appears the button in question adds a config option to your config to allow any tool, not just the specific tool. From context it very much appears to be a button that's meant to only allow the specific tool. It's inside a box with the tools name, and next to other button pertaining only to the specific tool.

Either it is meant to be the "always allow this tool" button like it appears to be, in which case the bug is that it puts the wrong config option in your config, or it's meant to be an "always allow any tool" button, in which case the bug is that it's not presented as such.

I got very surprised when the agent started running cargo commands to build and run my project without me having to confirm it first. I didn't even know there was a terminal tool, It's not listed among the tools you can configure when you go to customize a profile, and that was the first time I saw it being used.

Zed Version and System Specs

Zed: v0.185.13 (Zed) OS: Linux Wayland arch unknown Memory: 60.4 GiB Architecture: x86_64 GPU: AMD Radeon RX 5700 XT (RADV NAVI10) || radv || Mesa 25.0.5-arch1.1

[daviskirk]

For safety reasons there are a lot of things like this that would be very helpful. For example, I would like the agent to run test commands like pytest or vitest as often as it wants, but other commands or tools might be much more dangerous an require an "always ask" workflow

[dbrgn]

I second this. The current UI does not make it clear, whether I would "always allow" only this specific shell command, or any shell command.

Having a way to allow a specific list of shell commands (e.g. cargo check or cargo test) would be very helpful.

[tim-jagenberg-piscada]

I'd like to be able to control this behaviour on a per MCP tool basis.

I would always allow plain read-only tools, while I would want confirmations for all potentially mutating tools.

[bennetbo]

This works as expected, but I agree that this is not the ideal solution/can be confusing. We have plans to rework this feature in the coming weeks (similar to how it is described in this issue).

[oxplot]

I would always allow plain read-only tools, while I would want confirmations for all potentially mutating tools.

Risky:

• A read only tools may be pulling in sensitive data from a database the user doesn't want to send to OpenAI in a particular instance.
• There isn't a standard way to mark a particular MCP tool as having readonly properties, nor is there a way to enforce it should an MCP tool claim it to be.

---

Claude Code is an example of where this is done poorly in my opinion. I don't have a golden idea of what to do here, given the inherent poor security design of MCP. One idea with many holes in itself is to get an LLM (with custom prompt evalled for this particular purpose) to "vet" risk of a tool call in each instance with access to the tool call parameters (without context from the session so it's not biased towards allowing it in favor of task getting completed faster, as well reducing risk of prompt injection).

[agnosticlines]

I saw that another issue was closed as a duplicate of this one but I think the spec from https://github.com/zed-industries/zed/issues/34429 is worthy of being included in this issue, having that kind of granular and pattern based control would be super helpful

[vladiliescu]

+1 for this, I'm currently having to manually confirm each and every small script, since there's no way to only allow a safe subset of them (via regex or something similar).