Zed 1.14.2 Sandboxes Its AI Agent's Terminal and Fetch Tools by Default, Enforced at the OS Level
Zed's 1.14.2 release locks the code editor's AI agent into OS-enforced sandboxes for terminal and network access by default, using Seatbelt, Bubblewrap, or WSL depending on platform.
Overview
Zed Industries shipped version 1.14.2 of its code editor on August 5, 2026, enabling operating-system-level sandboxing by default for the AI agent panel’s terminal and fetch tools. LinuxCompatible reports the release “shipped on August 5, 2026, with its headline feature firmly locked in: OS-enforced sandboxing for the AI agent’s terminal and network tools.”
What We Know
The release notes describe the change directly: Zed “[a]dded sandboxing for the Agent’s terminal and fetch tools,” according to the v1.14.2 release notes. Zed’s official documentation explains the underlying approach: “Sandboxing instead uses OS features to forcibly restrict which resources a tool call has access to. This does not rely on an agent following a particular set of instructions. If the agent attempts to access a resource that is restricted by the sandbox, the OS will block it.”
In a blog post announcing the change, Zed engineer Cameron Mcloughlin wrote that “[t]he tension comes from the fact that agents cannot be trusted to determine whether an action is something the user would want,” and that “[i]n Zed, the agent panel’s terminal and fetch tools are now sandboxed by default. The default sandbox rules forbid an agent from writing outside the project directories, writing to .git, or making network requests.” Mcloughlin added that sandboxing “is enabled by default for all users, starting on the 1.14 release.”
The enforcement mechanism differs by platform. Zed’s documentation states that “[o]n macOS, Zed uses Apple’s Seatbelt sandbox through sandbox-exec,” while “[o]n Linux, Zed uses Bubblewrap (bwrap) for sandboxing,” and “[o]n Windows, Zed Agent sandboxing is supported only when the agent action runs inside WSL.” LinuxCompatible independently summarized the same split: “macOS users get Seatbelt out of the box, Linux relies on bubblewrap namespaces, and Windows agents are now gated behind WSL.”
Zed’s docs note that Linux requires “a runnable, non-setuid bwrap binary” on the system path, and that the sandbox “explicitly rejects setuid bwrap binaries” for security reasons. Git metadata receives special protection: per the documentation, “[g]it metadata writes are not grantable while a terminal command is sandboxed,” covering “.git directories, linked worktree metadata, refs, the index, hooks, local Git config, and other Git-controlled metadata files.” The blog post explains the rationale for that restriction specifically: “[t]he agent may not request write access to .git, since this allows an agent to write hooks that run outside the sandbox.”
When an agent needs access beyond the default restrictions, Zed’s documentation says it “shows a sandbox approval prompt before the tool action runs,” which can grant “network access to specific hosts,” “write access to specific filesystem paths,” or broader access, either for a single action, for the rest of a thread, or permanently — the latter saved to settings.json under agent.sandbox_permissions.
The blog post also details a vulnerability class Zed’s implementation defends against: a “symlink swap” attack, described as “a classic time-of-check-time-of-use (TOCTOU) bug” in which a malicious subagent could attempt to swap a granted directory for a symlink to an unauthorized one in the narrow window between user approval and sandbox creation. Mcloughlin wrote that “Zed’s sandbox does catch this attack and will fail-closed, meaning that the untrusted command will not be run.” LinuxCompatible corroborated this, noting that “Zed’s blog post spells out a symlink swap race condition as the most likely attack vector, and their implementation fails closed if it catches one.”
Both Zed’s own documentation and its blog post caution that sandboxing is not a complete defense. The documentation warns that an agent “may add a malicious Rust procedural macro to your codebase, which will be automatically executed by rust-analyzer outside the sandbox,” and frames the feature as “one layer in a defense-in-depth strategy” rather than a substitute for “good security practices.”
The same release bundled several unrelated changes. According to the release notes, Zed added a “Skip Hooks” toggle to the Git Panel’s commit menu that skips pre-commit and commit-msg hooks for a single commit, support for undoing and redoing file operations in the Project Panel, a reasoning-effort selector for Anthropic-compatible models, and configurable Agent Panel fonts through new agent_ui_font_family and agent_buffer_font_family settings. The release notes also record a breaking change: the default base_keymap moved from VSCode to Zed, with the VSCode option becoming a separate overlay — a shift that moves the inline assistant’s keybinding to cmd-i on macOS or ctrl-i on Linux and Windows, and gives f5 control of the debugger.
What We Don’t Know
Zed’s documentation acknowledges sandbox enforcement is weaker on Windows than on macOS or Linux, warning that “[u]nder some conditions, sandboxes on Windows are weaker than those on Linux and MacOS, and may not prevent all escape attempts,” without specifying how often those conditions arise in practice. Neither Zed’s release notes nor its documentation quantify how many bugs the 1.14.2 patch fixed in total; LinuxCompatible’s estimate that the release “patches roughly fifty bugs across crashes, Git panel state, and terminal process cleanup” is that outlet’s own count rather than a figure Zed itself published.
Analysis
The release lands amid a broader push by code editors to give AI agents more autonomy — as previously reported, Zed reached its 1.0 milestone in May 2026 built around GPU-accelerated, Rust-based editing. Sandboxing the agent’s terminal and fetch tools addresses a specific risk that Zed’s own blog post frames starkly: instruction-following alone cannot stop a compromised or adversarial agent, since “[f]ine-grained rules work well as a guideline when dealing with a well-aligned agent” but “fall over instantly in the presence of an even vaguely sophisticated attacker,” per the blog post. By moving enforcement to the operating system rather than the model, Zed is betting that OS-level sandboxes — despite acknowledged edge cases on Windows — offer a more durable defense than prompting alone as coding agents are granted broader access to developer machines.