How Zed's Agent Sandbox Works: No Writes Outside the Project, No .git, No Network — Unless the Agent Asks

If you let an AI agent run commands on your own machine, one question matters more than the rest: what can it reach? Zed’s answer is a sandbox — and specifically one enforced by the operating system rather than by the agent following instructions. Here is the practical version, drawn from Zed’s official “Sandboxing” post (verified 2026-09-09).

1. Default state: on for everyone since 1.14

Zed states it plainly: the agent panel’s terminal and fetch tools are now sandboxed by default, starting with release 1.14, for all users. The restrictions apply to what the agent can do with those tools, and they are enforced by the operating system and do not rely on an agent following instructions.

2. The three default rules

By default the sandbox forbids the agent from:

1. Writing outside the project directories
2. Writing to .git
3. Making network requests

Zed’s own assessment: for many interactions, this is more than enough.

3. When it needs more, it has to ask — and you decide

When the defaults are not enough, the agent can request a temporary privilege escalation. You see two things:

• which privileges it is asking for
• why it is asking

You can then grant the request once, for the rest of the thread, or permanently.

One exception is absolute: the agent may not request write access to .git. Zed explains why — write access there lets an agent install hooks, and hooks run outside the sandbox. Worth internalizing: the rule is not about protecting version control, it is about closing an escape route.

4. Platform implementations and prerequisites (Linux and Windows users, read this)

The sandbox is built on OS APIs:

The Windows line is the one that bites: if you run the agent from PowerShell or cmd, there is no sandbox. Getting the protection means working through WSL.

5. Why “just tell the agent not to touch those files” is not enough

This is the most valuable passage in Zed’s post. They concede the point: telling it works a lot of the time, and modern LLMs are pretty good at following instructions — but it is not a guarantee, and instructions do very little against prompt injection.

Their example is concrete. You maintain an open source project and you are reviewing a contributor’s PR. You open the agent and say “review this PR.” What you do not know is that the PR contains a modified AGENTS.md instructing your agent to upload $MY_SECRET_API_KEY to a server the attacker controls. Zed adds the cold part: this has already happened.

So the sandbox is not defending against some abstract fear of AI going rogue. It defends against instructions hidden inside the external content you yourself asked it to read. Which is our standing position too: what a tool reads is data, never commands.

6. Practical recommendations

1. Do not grant network access permanently just to save clicks. “Once” and “for this thread” exist precisely for this; permanent grants effectively disable the default protection.
2. PR reviews, unfamiliar repos, and stranger-filed issues are exactly when you need the sandbox — that is the common injection entry point.
3. Windows users: confirm you are actually in WSL. Outside it, the protection you assume you have does not exist.
4. Linux users: confirm bwrap is available. Zed lists it as a prerequisite; without it the sandbox does not engage.

Related verified pieces: How Zed Pro’s US$10 plan and US$5 token allowance work and Zed’s dev container secret logging leak. Plan status: Zed tool profile.

Sources

• Zed blog, “Sandboxing,” 2026-08-05: https://zed.dev/blog/sandboxing

Last verified: 2026-09-09