Zed (Agent panel)

Zed's agent runs with your own account and does nothing to narrow it. Every terminal command the agent runs inherits your full shell environment (including any API keys or cloud tokens exported there), and MCP servers inherit it too. Zed's own model-provider keys stay in the OS keychain and are not handed to tools. What limits the damage is not a narrower identity but other layers: the default sandbox blocks network and out-of-project writes, and every terminal command needs your approval.

Approval is on by default: every built-in tool that changes files, runs commands, fetches URLs, searches the web or invokes a skill, and every MCP tool, asks you first. For terminal commands you see the exact command, and allow/deny rules are regular expressions checked against each parsed sub-command of chained shell commands, with command substitution refused unless everything is auto-allowed. File edits are approved by path before the new content is shown, but every agent edit can be reviewed and rejected afterwards and Zed takes git checkpoints you can restore. Auto-approval for everything is a single ordinary setting with no loud name, and nothing undoes MCP or network side effects.

Zed's file tools are well scoped: paths are resolved against the project with symlink-escape checks, and files matching the private-files list (.env, keys, certificates) are refused by read and search. The fetch tool asks for each host, re-checks every redirect and refuses loopback, private and cloud-metadata addresses. But the default 'Write' profile also gives the agent a general shell, delete, and all MCP tools, and the shell accepts any command apart from command substitution; its reach is bounded only by the sandbox.

Agent terminal commands run inside a real OS sandbox by default on macOS (Seatbelt), Linux (bubblewrap with user, PID, IPC and network namespaces plus a seccomp filter that blocks Unix sockets) and Windows via WSL. Writes are limited to the open project and a temporary directory, Git metadata is read-only, and network is off. Leaving the sandbox needs a stated reason and your approval, and if bubblewrap is missing Zed asks rather than silently running on the host. But the sandbox can read your whole home directory and receives your full environment, so credentials are visible to anything the agent runs; MCP servers, language servers and remote (SSH) projects run without it, and sandbox boundary handling for project configuration does not cover every path.

Zed does not try to detect prompt injection, but its defaults blunt a hijack: every egress and state-changing tool (terminal, edits, fetch, web search, MCP) needs your approval whatever the agent has read, the terminal sandbox has no network, and read/search refuse .env and key files. The gap is the chat view itself, which is not locked down against unattended data egress. Tool results, files and MCP output all enter the conversation with no provenance marking.

Zed has no long-term memory store, and settings that could add MCP servers or language servers from a repository's .zed/settings.json only load after you explicitly trust that folder; agent permissions and sandbox settings can only be set in your user settings. Project skills also wait for trust, and the agent's edits to .zed/, .agents/skills/ or your config directory always prompt. However, instruction files in the project root (.rules, AGENTS.md, CLAUDE.md and similar) are loaded into the system prompt silently even in untrusted folders, and the agent can rewrite them (after an approved edit or command) to steer future sessions.

No third-party MCP server is enabled by default; you add one in settings (or a trusted project's settings), and its tools still need approval. Nothing pins or verifies MCP server code, and changed tool definitions are not re-approved. Zed extensions come from Zed's registry and auto-update by default, and the default capability grant lets them run any process, download any file and install any npm package. MCP servers launch as ordinary processes with your full environment.

Zed keeps its own model-provider keys in the OS keychain, and the agent's read and search tools refuse files on the private-files list (.env, keys, certificates) by default. There is no redaction of tool output sent to the model, of logs, or of saved conversation history, and terminal commands and MCP servers inherit your full environment, so any key exported in your shell is within reach of a command the agent runs. Usage metrics and crash reports are on by default; agent telemetry events carry metadata (model, token counts), not prompts.

Each agent thread, including its tool calls, tool results and sub-agent threads (linked to their parent), is saved to a local database in Zed's data directory, outside the project the agent can write to. The record has no per-call timestamps and does not record your approvals or denials, saves are whole-thread snapshots whose failures are only logged, and there is no tamper evidence or export.

There is no limit on how many steps, how long, or how many tokens an agent turn may use. MCP calls time out after 60 seconds by default, model retries are capped, and terminal commands only time out if the model asks for a timeout. Stopping works well: cancel stops the turn, cancels running sub-agents and kills running terminal commands.