Zed Agent: Auto approval routing via classifier model

[gianpaj]

What are you proposing?

Add an Auto permission mode to Zed Agent.

In Auto mode, a separate reviewer model would inspect permission-gated actions before they run. It would decide whether each action is safe and consistent with the user's request.

The reviewer should return one of three decisions:

• allow: run the action without interrupting the user
• deny: block the action and tell the Agent why
• ask: use Zed's existing approval prompt

The reviewer should be configured independently from the main agent model. Users could select any model available through Zed's existing LLM providers, including a local model through Ollama.

Existing permission rules would remain in place. Explicit deny rules, protected paths, and sandbox restrictions must always take precedence over the reviewer.

The reviewer model should be configured separately from the main Agent model. Users could choose any model available through Zed's LLM providers, including a local model through Ollama or an OpenAI-compatible server.

Auto mode should complement Zed's existing tool permissions and sandbox, not replace them. Deterministic deny rules, protected paths, and sandbox restrictions must remain authoritative.

Why does this matter?

Zed's current tool permissions work well for actions that can be described with stable rules. Users can allow, deny, or confirm terminal commands and other tools using patterns.

Many real actions depend on context, though.

For example:

• git push may be expected when the user asks to publish a branch, but unexpected during a code review.
• An HTTP request to a package registry may be part of installing dependencies, while sending workspace data to an unknown endpoint should require approval.
• Editing files inside the current project is usually routine. Writing to shell configuration, credentials, or files outside the workspace is not.
• An MCP tool may be safe for reading data but sensitive when it creates an issue, sends a message, or changes production state.

Static rules cannot determine whether an action matches the user's request. This leaves users choosing between frequent approval prompts and broad allow rules.

Auto mode would reduce those interruptions without granting unrestricted access. It would help long Agent tasks continue on their own while preserving approval for actions that are risky, unclear, or outside the requested scope.

A configurable reviewer would also give users control over:

• Privacy: the reviewer could run locally through Ollama.
• Cost: a small model could review actions while a larger model performs the task.
• Latency: users could choose a fast classifier suited to their hardware.
• Trust: teams could select or host the model responsible for permission decisions.

Are there any examples or context?

Claude Code's Auto mode uses a separate classifier to review actions before execution. Existing permission rules run first, common workspace operations skip the classifier, and unresolved actions receive model review. The classifier sees user instructions and tool calls but excludes tool results, which may contain hostile content. Repeated denials eventually pause Auto mode and restore normal approval prompts.

Existing open-source project that explores related designs:

• pi-automode applies a separate configurable classifier to shell commands, file changes, MCP tools, network actions, and subagents. It is the closest example of a general-purpose Auto permission mode.

This project suggests a useful combination for Zed:

• Follow pi-automode in supporting the full range of Agent tools and a separately configured model.
• Use Zed's approval UI to support an explicit ask result.

Zed already has the main pieces: tool permissions, Agent sandboxing, configurable LLM providers and local models, and support for external agents through ACP.

Possible approach

Agent action
     ↓
Permissions and sandbox
     ↓
Known safe? ── yes → Run
     │
     no
     ↓
Configurable reviewer
  ↙     ↓      ↘
Allow  Deny    Ask user

Keep deterministic rules as the first layer:

1. Apply explicit allow, confirm, and deny rules.
2. Preserve hard denies, protected paths, and sandbox restrictions.
3. Allow actions Zed already considers safe, such as reads and ordinary workspace edits.
4. Send unresolved actions to the configured reviewer model.

The reviewer request could contain:

• The current user request and any explicit boundaries
• The tool name and normalized arguments
• The workspace and trusted-path context
• The permission rules that apply to the action

Raw file, terminal, and web content should not be included by default, as they may contain prompt injection.

The reviewer could return a small structured response:

{
  "decision": "allow | deny | ask",
  "reason": "Short explanation"
}

Related GH discussions:

• Add setting to auto-approve external ACP agent tool permissions #57402