Source: Zed Industries — 2026-08-05
Summary
Zed 1.14 (v1.14.2) made sandboxing the default for the agent panel's terminal and web-fetch tools, enforcing restrictions at the OS level rather than relying on the model to simply follow instructions. By default the agent can't write outside the current project directory, touch the .git folder, or make network requests, unless the user explicitly grants an escalation — once, for the current thread, or permanently. The mechanism is platform-specific: Seatbelt on macOS, Bubblewrap namespaces on Linux, and WSL2 on Windows, and Zed frames it as resolving the tradeoff between tedious per-action human approval and fully unrestricted agent execution.
Key Takeaways
- The core shift is enforcement layer: previous safety relied on the model choosing to follow prompted rules, while this relies on the operating system physically blocking the action regardless of what the model decides to do.
- Default-deny scope is specific and sensible: no writes outside the project directory, no touching
.git, no network requests — the three most common ways an unsupervised agent could do real damage. - Escalation is granular by design: a user can grant permission once, for the current thread only, or permanently, rather than a single global on/off switch.
- The implementation isn't one cross-platform trick — it's three separate OS-native sandboxing primitives (Seatbelt, Bubblewrap, WSL2), meaning Zed did the work to make the guarantee real on each platform rather than emulating it uniformly.
- Zed's own framing is explicit: this is meant to let agents run unattended, because a kernel-enforced boundary — not a prompt — is what actually stops damage, which is a direct statement that prompt-level safety instructions were never sufficient on their own.
Reel Script
Hook (18s)
Every AI coding agent is told, in plain English, "don't touch files outside the project, don't touch git, don't hit the network." Zed just stopped trusting that sentence — and built an actual operating-system wall around the agent instead.
Core Concept (70s)
Here's the actual problem this solves. When you give a coding agent terminal access, the only thing normally stopping it from deleting your git history or exfiltrating a file over the network is the model's own judgment — it read an instruction saying "don't do that" and it's choosing to comply. That's a prompt-level guardrail, and prompts can be misread, jailbroken, or just get it wrong. Zed's answer in version 1.14 is to move that guardrail down a layer, to the operating system itself. Think of the difference between telling a contractor "please don't go into the back office" versus literally locking the back office door. Zed now sandboxes the agent panel's terminal and web-fetch tools by default, using the OS's own permission primitives — Seatbelt on macOS, Bubblewrap on Linux, WSL2 on Windows — so the restriction is enforced by the kernel, not by the model remembering its instructions. The agent physically cannot write outside your project folder, touch .git, or hit the network unless you say otherwise.
Hands-On (55s)
Walk through the actual default ruleset: three things are blocked out of the box. No writes to any path outside the current project directory — so the agent can't touch your home folder or other repos. No access to the .git folder — so it can't rewrite history or mess with your version control state underneath you. No outbound network requests — so it can't call an external API or leak a file without you knowing. If the agent genuinely needs one of those — say, hitting an API during a web-fetch step — you get to grant that specific escalation, and you choose the blast radius: allow it just this once, allow it for the rest of this thread, or allow it permanently going forward.
Takeaway (25s)
My take: this is the correct fix, not a nice-to-have — per-action approval prompts don't scale and pure trust-the-model is reckless, so kernel-level sandboxing is the only version of "let the agent run unattended" that's actually safe. If you're running agent terminal access anywhere, go check whether your tool enforces this at the OS level or just asks nicely.