Zed Agent: More convenient ways to allow commands to AI agents (visual highlight, preconfigured groups, regex debugging)

[gerion0]

What are you proposing?

Currently, Zed allows to define regexes to allow shell commands for AI agent tool usage. I like that mechanism because it is very powerful. However, these regexes, for being useful, become quite complex very fast.
I want to propose several mechanisms to make this much easier to configure:

Visual highlight of already allowed command parts

AI agents often concatenate multiple UNIX tools in one command line:

echo "---" && git --no-pager status && echo "---"

Zed already recognizes these groups and provides a GUI interface to allow ^echo\b and ^git.... I want to propose a visual feedback of that: In the agent window, visually highlight all already accepted commands (e.g. coloring them in green), and visually highlight all yet to allow commands differently (e.g. coloring them in yellow).

The advantage is that the user has a much faster visual indication what commands are "new" in the tool chain that needs approval.

Predefined allowence groups

Some commands are quite common for agents, e.g. echo, ls, cut, sed, git. Some of these commands are quite uncritical to allow, e.g. echo, while others are uncritical for certain subcommands, e.g. for git one can allow all read-only commands but want to always approve commands like commit and push.

However, doing this via regex is hard. For example, I tried:

^git(?:\s+--\S+)*\s+log\b

to allow commands like:

git log
git --no-pager log some-branch-name
git log 2c7737f..2712ab

Somewhere in this regex is an error (the agent keeps asking me for git log commands) and I'm sure that I forgot some corner cases.

My suggestion is: Provide preconfigured regex groups delivered as part of the editor to allow e.g. "read-only git commands". This can be combined with a nice GUI: When an agent asks for approval of a git command, Zed can try all preconfigured regexes, check if one matches, and present the user this specific group as an alternative to allow:

• allow this specific git command
• allow the group "Read-only git commands"

Regex debugging tool:

Currently, the process is: The agent ask for a specific command to allow, the user can click on the "command" list, the regexes for exact these commands are transferred to the settings, the user then go to settings and try to make the commands more generic, but there is no possibility for testing it.
The user has to wait until the agent asks the next time to check if the regex actually worked or not. Regexes are error prone, so I want to suggest two ways for testing:

• A test field in the settings window: Enter a string/command there and it gets a checkmark or similar when it is allowed under the current configuration.
• Capture the list of the 10 last commands, display them in the settings windows and indicate visually what commands would be allowed and what not.

More advanced would be a regex testing tool like proposed in #62071.

Suggest prefixes

Zed has already a GUI way so that the user can allow the individual commands in a long chain of commands. I want to suggest a visual way to extend that also to command prefixes.
E.g. when the command is

git --no-pager log some-branch-name

then allow the user to whitelist:

• git
• git --no-pager
• git --no-pager log
• git --no-pager log some-branch-name

This provides an easy way to allow "subcommands".

One step further: Include the agent

Since the commands are controlled by an agent. It can be also used for them:

Make the agent aware of allowed commands

For a lot of UNIX tools multiple ways exist to achieve the same, e.g. string manipulation via cut, sed, awk. The agent prompt should get the list of allowed tools (the regexes) so that it can prefer the tools on the allow list.

Let the agent create the regexes

What probably also works is to ask the agent to create the allow regexes in the most generic way, so when Zed encounters an unknown command, it currently asks the user to allow. It can also:

• Stop the agent.
• Ask it to provide multiple regexes that are generic to command groups this particular command can belong to (e.g. "git read-only commands" "all git-commands", "all git log commands").
• Present the result to the user.
• Continue with the original tool call, after the user's decision.

Let another AI decide about the command approval. This is already discussed here: #63092

Why does this matter?

All of the above proposals greatly simplify "tool approvals" without the need for regexes or simplifying the usage of those.