By Zed shipped OS-level agent sandboxing in its preview channel last week, and the timing is not coincidental. Six weeks after GuardFall proved that shell injection bypasses the safety checks of 10 out of 11 AI coding agents, Zed pushed a fix that operates below the agent itself — at the operating system’s process boundary. It’s opt-in, it’s still in preview, and it has a gap that most Zed users will hit immediately. Here’s what changed and what to do about it.
What the Sandboxing Actually Does
On macOS, Zed wraps every shell invocation the AI agent makes inside Apple’s sandbox-exec(1) with a custom Seatbelt policy. The effect is straightforward: reads are unrestricted, writes are locked to an explicit allowlist of directories you control, and network access runs through an HTTP/HTTPS proxy so Zed can limit it to approved hosts. Three things are blocked entirely regardless of what you approve: LaunchServices (which can spawn processes outside Zed), the system pasteboard (clipboard), and audio capture.
On Linux, Zed uses Landlock and seccomp — the same kernel primitives Cursor’s sandbox relies on. Windows gets WSL2-based sandboxing, with Git metadata protected by default unless you explicitly approve access.
One important distinction: the fetch tool, which lets the agent retrieve web content, runs entirely outside the OS sandbox. It has its own permission model governed by tool permissions and project trust settings — but the Seatbelt policy does not touch it. That matters for prompt injection attacks that arrive via web content the agent fetches.
The Gap You Will Probably Hit
If you use Claude Code as your agent inside Zed, the sandboxing does not apply to you. GitHub issue #47763 is open: Claude Code does not currently support Zed’s sandboxing mechanism. Zed is a Rust-native editor that attracts a significant share of Claude users — this is the most inconvenient gap in the feature. The issue is open and active; expect it to close in the next few releases. But right now, if you’re on Claude Code in Zed, sandboxing does nothing for you.
The other supported agents — including Zed’s native AI integration with Anthropic models, Mistral, and others — do support sandboxing.
How to Enable It
Sandboxing is not in Zed’s stable 1.13.1 release. You need the preview build. Once installed:
- Open the command palette and run agent: open settings
- Navigate to the AI section
- Enable sandbox mode for the agent
- Configure write paths — the directories the agent is allowed to write to
The latest preview improved permission prompts: when the agent requests a write to a path outside your allowlist, Zed now shows a clear file list of the requested paths instead of a generic permission dialog. Temporary files are also now preserved across commands in the same agent thread — a usability fix that was blocking multi-step workflows.
What It Protects and What It Misses
This sandbox stops a specific category of attack: a malicious MCP server or injected prompt that tells your agent to run rm -rf ~/.ssh/, write to your AWS config, or exfiltrate credentials to an unexpected host via curl. Those fail under the sandbox because writes outside approved directories are blocked and raw network tools — SSH, FTP, raw sockets — do not go through the proxy-only network gate.
What it misses is narrower but real. If an attacker injects instructions through web content the agent fetches, those instructions run outside the sandbox. The fetch tool gap means prompt injection via web content remains possible. The sandbox only constrains the agent’s OS-level outputs — it does not stop the agent from being manipulated into doing something harmful within its approved scope.
| Editor | Sandbox Method | Default On? | Fetch Protected? |
|---|---|---|---|
| Zed (preview) | macOS Seatbelt / Linux Landlock | No | No |
| Cursor | macOS Seatbelt / Linux Landlock / WSL2 | Yes (enterprise) | Yes |
| VS Code | Prompt-level approvals only | No | N/A |
| Nono | Full VM isolation | Yes | Yes |
The Rest of Zed 1.13.1
The stable release that shipped July 29 is a meaningful update outside the sandboxing story. Per-response controls now let you stop or retry individual responses inside a multi-turn agent conversation without abandoning the whole thread. Mistral Medium 3.5 and Small 4 get thinking support. Dev containers created in Zed can now be reused directly by VS Code and the CLI — an interoperability win for teams that mix editors. Linux users on KDE Wayland get a fix for a Fcitx5 memory leak, and Git auth timeout issues that blocked slow authentication flows are resolved.
What to Do Now
If you’re running Zed with any agent that touches production configs, .env files, SSH keys, or cloud credentials: install the preview build and enable sandboxing today. The protection is real even if it’s incomplete. If you’re on Claude Code, watch issue #47763 — that’s the blocker for you specifically.
OS-level sandboxing enforced by the kernel rather than by the agent’s own judgment is a fundamentally different security guarantee. Approved scope enforced at the OS boundary is worth the preview build upgrade — just go in knowing the fetch tool gap is still open.
