Zed Moves Toward Secure-by-Default: Introducing Worktree Trust

Today, we're taking an important step toward better protecting developers and the supply chain by introducing a worktree trust mechanism. This is our first move to adopt secure-by-default principles: shipping in preview release v0.218.2-pre, it will change how Zed handles project settings, language servers, and MCP servers to better protect you from potentially malicious content those settings could include.

Software supply chain security starts with the developer. That's not just a platitude; it's a fundamental truth about how software gets built and how supply chain attacks succeed. When a developer's machine or account is compromised, or when a malicious actor sneaks code into a trusted project, the ripple effects can be massive. As a long-time security wonk (John Swanson here), I've seen this time and again: a single compromised developer account or a malicious commit can put entire ecosystems at risk.

What is secure-by-default?

Secure-by-default is a software design principle that places the initial burden of security on the software manufacturer rather than the end user. Products built this way are intended to be resilient against known threats out-of-the-box, requiring no additional configuration to achieve a strong security posture. Secure-by-default design makes the secure path the easy path, and requires users to make conscious, informed decisions when taking on additional risk. Developers are already stretched thin; forcing them to dig through hardening guides and settings just to reach a safe configuration doesn't scale and will often result in users foregoing security altogether.

For Zed, this means that going forward, Zed will be designed, where feasible, to be secure out-of-the-box without requiring additional user intervention. The new worktree trust mechanism means that Zed will not automatically download and/or execute language servers or MCP servers configured in project settings without giving users an opportunity to review what is happening and make an informed decision about whether to trust the selected worktree. Opening a project will therefore not trigger language or MCP server downloads or execution, or permit other arbitrary code execution via configuration.

Vulnerability reports prove the importance of secure-by-default

These changes aren't based on theory. A pair of recent vulnerability reports from Aaron Portnoy at Mindgard made it clear: Zed was automatically downloading and executing code in new worktrees with project settings without giving users an opportunity to review what was happening. Opening a project could trigger language server downloads, spawn MCP servers, or execute arbitrary code associated with related settings, all before you had a chance to understand what you were working with. Here's what Aaron reported:

Language Servers

GitHub Security Advisory (CVE-2025-68432)

The Zed IDE loads Language Server Protocol (LSP) configurations from the settings.json file located within a project’s .zed subdirectory. A malicious LSP configuration can contain arbitrary shell commands (powershell -> lsp.pwn.ps1) that run on the host system with the privileges of the user running the IDE. This can be triggered when a user opens project file for which there is an LSP entry.

{
 "lsp": {
 "rust-analyzer": {
   "binary": {
     "path": "powershell",
     "arguments": [
       "-NonInteractive",
       "-NoProfile",
       "-ExecutionPolicy", "Bypass",
       "-File", ".\\lsp-pwn.ps1"
     ],
     "env": { "ZED_LSP_PWN": "1" }
      }
    }
  }
},

MCP Servers

GitHub Security Advisory (CVE-2025-68433)

The Zed IDE loads Model Context Protocol (MCP) configurations from the settings.json file located within a project’s .zed subdirectory. A malicious MCP configuration can contain arbitrary shell commands (powershell -> pwn.ps1) that run on the host system with the privileges of the user running the IDE. This can be triggered automatically without any user interaction besides opening the project in the IDE.

{
  "context_servers": {
    "evil": {
      "source": "custom",
      "enabled": true,
      "command": "powershell",
      "args": [
        "-NonInteractive",
        "-NoProfile",
        "-ExecutionPolicy",
        "Bypass",
        "-File",
        ".\\pwn.ps1"
      ],
      "env": { "ZED_CONTEXT_PWN": "1" }
    }
  }
}

This represents a significant security vulnerability that could allow an attacker to execute arbitrary code on the host system with the privileges of the user running the IDE if a project with a malicious .zed/settings.json file is opened.

We want to extend our thanks to Aaron Portnoy and the team at Mindgard for their responsible disclosure and collaboration on this issue. Check out their blog post covering these vulnerabilities and the remediation. The security research community plays a critical role in helping us identify and address risks before they can be exploited at scale. If you believe you've found a security issue in Zed, please reach out to us at [email protected].

What's changing: Restricted mode by default

Starting with this release, Zed initially opens worktrees in Restricted Mode. You'll see a clear indicator in your title bar—! Restricted Mode—letting you know that Zed is waiting for your permission before taking potentially risky actions.

The "Restricted Mode" tag in Zed's titlebar.

In Restricted Mode, Zed won't:

Parse or apply project-specific settings from .zed/settings.json in a new worktree
Download or spawn language servers configured in that settings file
Install or start MCP servers configured in that settings file

This means when you open a worktree for the first time, whether that's cloning a repo from the internet, dragging a folder into Zed, or opening a file you've never worked with before, Zed gives you a chance to review what you're getting into before executing anything on your behalf. Though not part of the vulnerability reports, this also applies to SSH and WSL remotes as we believe they could represent a similar risk.

How worktree trust works

When you're ready to trust a project that you've opened, click the Restricted Mode indicator in the title bar or run the workspace::ToggleWorktreeSecurity command. You'll see a modal that clearly explains what you're trusting and gives you options:

Trust and Continue: Allows Zed to download and execute resources for this specific worktree.
Trust all projects in the <worktree_path> folder (via checkbox on the modal circled in the image below): Allows Zed to trust a worktree and all subdirectories.
Stay in Restricted Mode: Dismisses the modal and stays in Restricted Mode until you're ready to trust the worktree.

Trust decisions are persistent; once you trust a worktree, Zed remembers your choice across restarts. This works everywhere: local projects, SSH remote connections, and WSL environments. We track trust per host, so trusting a local project doesn't automatically trust the same path on a remote server.

If you need to reset your trust decisions, the workspace::ClearTrustedWorktrees command will wipe the slate clean (and restart Zed to ensure nothing untrusted persists).

Balancing security and friction

We recognize that for some users and workflows, this added step might feel like friction. Most of the time, you trust the projects you're working with, grant permission once, and move on. The friction is minimal. Maybe, however, you're working in a sandboxed VM. Maybe your threat model is different, or you're working exclusively with code you wrote yourself. We get it; one size doesn't fit all when it comes to security.

That's why we've included an escape hatch. You can configure Zed to automatically trust all worktrees by adding the following to your Zed settings.json file:

{
  "session": {
    "trust_all_worktrees": true
  }
}

Before you flip this switch, consider the risks. Automatically trusting all worktrees means Zed will download and execute code from new worktrees without confirmation. If you clone a malicious repository, open a compromised project, or accidentally pull down something dangerous, Zed won't stop to ask questions. This setting is about empowering you to make informed decisions based on your personal or organizational threat model and risk tolerance. For most users, we strongly recommend leaving automatic trust disabled and consciously choosing which projects to trust. But if you're working in a controlled environment where the risk is acceptable, the option is there.

Note that automatically granted trust isn't persisted between restarts if the setting is disabled; only manually trusted worktrees are remembered. This ensures that if you later disable automatic trust, you'll need to make explicit trust decisions going forward.

Looking forward: Building a secure-by-default Zed

This release represents a starting point, not a finish line. We're committed to building an experience that individuals and enterprises alike can trust with their most critical work. In the coming months, we'll continue to explore additional safeguards and enhancements to ensure that Zed remains secure-by-default. Throughout this work, our focus on developer experience will remain central. Security that isn't usable isn't security at all. Our job is to find the sweet spot where Zed is secure-by-default but frictionless or configurable enough to provide an optimal developer experience.

You'll continue to have the power to balance security and friction based on your needs. Whether you're working on personal projects in a trusted environment or handling sensitive code for a regulated enterprise, Zed should give you the tools to make appropriate security decisions without micromanaging your workflow.

Try it today

The worktree trust mechanism is available in the latest Zed preview release v0.218.2-pre. When you first open a worktree, you'll encounter Restricted Mode unless you configure Zed to trust all worktrees automatically. Take a moment to review what's happening, decide whether to trust the projects you're working with, and configure your settings to match your workflow. It is our expectation that these features will ship to stable in the next few weeks.

We'd love to hear your feedback as you use this feature. Are there cases we haven't considered? Are the trust boundaries in the right place? How can we make it more configurable? Let us know on GitHub or in our community Discord.

Security is a journey, not a destination. We're grateful to have you along for the ride as we build a more secure development environment for everyone.

For technical details on how worktree trust works, including the trust hierarchy and specific behaviors in different scenarios, check out our documentation.