Software supply chain attacks are on the rise, and developer environments are a prime target. Recognizing the risks, Zed is shifting the paradigm by introducing a worktree trust mechanism in its preview release v0.218.2-pre. This innovation aims to protect both developers and the broader ecosystem by ensuring that potentially risky project settings or server code are only executed with explicit user consent.
What Is Secure-by-Default?
Traditionally, users bear the brunt of securing their tools. Zed’s secure-by-default philosophy reverses this: security is built in from the start, making it the effortless choice. Developers no longer need to sift through documentation or tweak obscure settings, Zed prompts users to explicitly review and trust a project before applying configurations or running server code. This approach blocks automatic execution of code from configuration files, offering robust protection against common attack vectors.
Real-World Risks Demand Real Solutions
Recent vulnerabilities highlighted by Aaron Portnoy at Mindgard revealed that Zed’s earlier versions could automatically execute untrusted code via project settings or language servers. Attackers could exploit this by embedding malicious commands within project configurations, compromising systems instantly. These concerns, tracked as CVE-2025-68432 and CVE-2025-68433, underscored the urgent need for user empowerment and tighter controls.
Restricted Mode: Safety by Default
With the new release, Zed now opens projects in Restricted Mode by default, clearly indicated in the title bar. While restricted, Zed will:
- Ignore project-specific settings from
.zed/settings.json - Block automatic downloads or launches of language and MCP servers
- Prevent arbitrary code execution from project configurations
This protection applies whether opening a fresh repo, connecting via SSH, or using WSL. Developers get a chance to review project settings before any action is taken.
How the Worktree Trust Mechanism Operates
When you’re ready to trust a project, simply click the Restricted Mode indicator or run workspace::ToggleWorktreeSecurity. A modal will guide you through:
- Trust and Continue: Grants permission for the current worktree
- Trust all projects in the folder: Applies trust across the directory and subfolders
- Stay in Restricted Mode: Maintain maximum safety until you decide
Trust choices persist across restarts and are specific to each host, giving you granular control,especially useful for remote or virtual environments. If needed, use workspace::ClearTrustedWorktrees to reset all trust decisions and restart Zed for peace of mind.
A Thoughtful Balance: Security Meets Usability
While new security layers can introduce friction, Zed minimizes disruption. Most users will only need to trust a project once. For advanced cases, an “escape hatch” exists: setting "trust_all_worktrees": true in Zed’s settings bypasses individual prompts. This option is clearly marked as risky and is best for low-threat or isolated environments. Manual trust is always secure and persistent, while automatic trust is not retained if the setting is disabled later.
Continuous Security Improvement
This worktree trust mechanism is only the start of Zed’s secure-by-default journey. The team is committed to strengthening safeguards while keeping workflows smooth. Developers can confidently protect both enterprise and personal projects without constant micromanagement.
Try It and Shape the Future
The worktree trust feature is live in Zed’s preview, with a stable release coming soon. Developers are encouraged to test it, tailor their trust settings, and share feedback via GitHub or Discord. User insights will help refine Zed’s security boundaries and options, ensuring protections keep pace with evolving threats.
Security is an ongoing journey, and Zed is determined to create a safer, more flexible environment for every developer.
Source: Zed Blog | John Swanson & Kirill Bulatov at Zed
Zed IDE Reinvents Developer Security with Worktree Trust Mechanism