Which agent tools does Zed 1.14 sandboxing cover?

Zed 1.14 sandboxing wraps the agent panel's terminal and fetch tools — the two tools that can otherwise shell out to arbitrary commands or hit any URL. Other operations still ride the built-in Zed permission prompts and file-edit approvals, so an agent asking to write outside the project still surfaces to the user.

What does Zed 1.14 block by default when an agent runs?

By default a Zed 1.14 agent cannot write files outside the current project directory, cannot write anything under .git even inside the project, and cannot make network requests from the terminal tool. Read access is unrestricted, and reads or writes inside the project's non-.git files continue to work as before.

Which operating systems does Zed 1.14 sandboxing support?

Zed 1.14 sandboxing runs on macOS via Apple's Seatbelt (sandbox-exec) and on Linux via Bubblewrap using kernel namespaces. On Windows, only agents inside WSL are sandboxed — commands in native PowerShell or cmd shells are not, so Zed leans on WSL for the same guarantees.

How do users grant an agent extra permissions in Zed 1.14?

When an agent needs elevated access — write outside the project, edit .git, hit the network — Zed 1.14 pops a prompt naming the exact resource and the agent's reason. The user can grant that permission just once, only for the current thread, or permanently save it for the workspace.

Is Zed 1.14 sandboxing enough to stop a fully malicious agent?

Zed describes sandboxing as one layer in defence in depth, not a complete answer. A hostile model could still exfiltrate via files it is allowed to edit, git hooks, or procedural macros run outside the sandbox, so Zed keeps its permission prompts, file-edit approvals, and file-based reviews on top of the OS backend.

Zed Industries · 2026-08-05 · major

Zed 1.14 Sandboxing — OS enforces what agents can touch

Zed 1.14 turns on OS-level sandboxing by default for its agent panel. Agents can no longer write outside the project, edit .git, or open network requests unless the user grants a specific permission at the OS layer.

Zed 1.14 sandboxing blog cover art showing an isolated agent environment

Zed 1.14 makes the OS the wall around your coding agent, not the agent's promise to behave.

Quick facts

Maker	Zed Industries
Version	Zed 1.14 (stable)
Default	Sandboxing on by default in the agent panel
Blocked by default	Writes outside the project, .git writes, all network requests
macOS backend	Seatbelt (sandbox-exec)
Linux backend	Bubblewrap (kernel namespaces)
Windows backend	WSL only; non-WSL shells not sandboxed
Escalation	Per-request prompt: once, per thread, or always

What is it?

Zed 1.14 turns on OS-level sandboxing by default whenever an agent uses the editor's terminal or fetch tools. The Zed editor now runs each agent tool call inside a real operating-system sandbox — Apple Seatbelt on macOS, Bubblewrap on Linux, WSL on Windows — that blocks writes outside the project, blocks touching .git, and blocks all network requests until the user says otherwise.

How does it work?

Each agent shell command in Zed 1.14 is spawned under an OS backend that enforces the allow-list at the kernel or hypervisor layer — sandbox-exec on macOS, unshare-based namespaces via Bubblewrap on Linux, and a WSL boundary on Windows. When an agent asks to break out — write to a system path, push to git, hit the network — Zed intercepts the syscall, shows a prompt naming the resource and the agent's stated reason, and only lifts the restriction after the user picks once, thread-scoped, or persistent.

Why does it matter?

The Zed 1.14 sandbox moves agent safety from please-behave prompts to hard OS boundaries, at exactly the moment UK AISI is disclosing agents that opened GitHub accounts and pushed malicious commits during cyber evaluations. Teams shipping coding agents into shared repos get a real fail-closed default they can point at when auditors ask how a Claude or GPT run cannot rm -rf the machine.

Who is it for?

developers running AI coding agents in a real project directory

Frequently asked questions

Which agent tools does Zed 1.14 sandboxing cover?: Zed 1.14 sandboxing wraps the agent panel's terminal and fetch tools — the two tools that can otherwise shell out to arbitrary commands or hit any URL. Other operations still ride the built-in Zed permission prompts and file-edit approvals, so an agent asking to write outside the project still surfaces to the user.
What does Zed 1.14 block by default when an agent runs?: By default a Zed 1.14 agent cannot write files outside the current project directory, cannot write anything under .git even inside the project, and cannot make network requests from the terminal tool. Read access is unrestricted, and reads or writes inside the project's non-.git files continue to work as before.
Which operating systems does Zed 1.14 sandboxing support?: Zed 1.14 sandboxing runs on macOS via Apple's Seatbelt (sandbox-exec) and on Linux via Bubblewrap using kernel namespaces. On Windows, only agents inside WSL are sandboxed — commands in native PowerShell or cmd shells are not, so Zed leans on WSL for the same guarantees.
How do users grant an agent extra permissions in Zed 1.14?: When an agent needs elevated access — write outside the project, edit .git, hit the network — Zed 1.14 pops a prompt naming the exact resource and the agent's reason. The user can grant that permission just once, only for the current thread, or permanently save it for the workspace.
Is Zed 1.14 sandboxing enough to stop a fully malicious agent?: Zed describes sandboxing as one layer in defence in depth, not a complete answer. A hostile model could still exfiltrate via files it is allowed to edit, git hooks, or procedural macros run outside the sandbox, so Zed keeps its permission prompts, file-edit approvals, and file-based reviews on top of the OS backend.

Try it

Update Zed to 1.14 stable — sandboxing is on by default in the agent panel.