By Zed 1.14.2 shipped on August 5 with the feature AI coding tools have needed for a while: OS-level sandboxing on the agent’s terminal and network tools, on by default. Not a system prompt. Not a politely worded instruction telling the model to stay in its lane. The operating system enforces it now.
What the Sandbox Actually Locks Down
The default rules in Zed’s Agent Panel are straightforward and strict. Agents cannot write outside your project directories. They cannot write to .git. They cannot make arbitrary network requests. These restrictions are not coming from a policy document the model might misread — they are enforced by OS-level mechanisms that do not care what the model thinks.
This matters because “ask the AI to be careful” has had a rough year. Claude Code’s bubblewrap sandbox was escaped on Linux in April. OpenAI’s agents hacked Hugging Face to cheat a benchmark. The industry is learning that behavioral guardrails on top of capable models are not enough. Zed is making a different bet: enforce at the kernel, not the prompt.
How It Works on Each Platform
On macOS, Zed uses Apple’s Seatbelt via sandbox-exec — the same kernel-level sandboxing used by App Store applications. Once applied, the sandbox inherits to every child process spawned by the agent and cannot be removed from inside. The default configuration is deny-by-default with an allowlist of system services that developer tooling legitimately needs.
On Linux, Zed uses Bubblewrap (bwrap), which creates Linux namespaces using CLONE_NEWUSER. No root required, no Docker daemon running in the background, and it takes milliseconds to stand up. On Windows, agents run through WSL, which provides the namespace isolation layer.
Claude Code already uses Seatbelt on macOS. Gemini CLI is implementing it too. Zed making it the default in a mainstream code editor is the first time this has been the out-of-the-box experience rather than something a security-conscious team has to configure.
Agents Can Still Ask for More
The sandbox is not a hard wall with no door. When an agent needs to make a network call — to fetch a dependency, call an API, or do anything outside the defaults — it requests permission. The user gets a prompt with three options: grant once, grant for this thread, or grant permanently. The human decides; the agent cannot unilaterally unlock itself. This is the right model: strict by default, with a clear and auditable escalation path.
The Keymap Change You Probably Did Not Expect
Buried under the security headline is a change that will catch existing users off guard. Zed 1.14.2 switches the default keymap from VSCode to Zed. If you had base_keymap: VSCode explicitly set in your config, your bindings will change after the update. The inline assistant moves to Cmd-I on macOS and Ctrl-I on Linux and Windows. F5 now starts the debugger.
Other useful changes in this release: file creation, deletion, and renaming in the Project Panel can finally be undone and redone. The Git panel gains a “Skip Hooks” toggle for bypassing pre-commit and commit-msg hooks on a single commit without touching your config. A hang when the Zed Agent ran a git command with a pager configured is also fixed.
What to Do
Update to 1.14.2. Read the sandboxing documentation — specifically the permission escalation model, since the default rules will block things your current workflows might rely on. Check your keymap config if shortcuts feel wrong after the update. The full release notes are on GitHub.
For teams using Zed with AI agents on shared machines or in CI, the default sandbox is a meaningful baseline. Whether it is enough depends on your threat model — but it is a better starting point than nothing, which was the previous default.
