Zed extensions are different from VS Code extensions, and that matters more than you'd think
Published 2026-04-26 by Owner
I’ve been moving back and forth between Zed and Cursor for the past month. The biggest day-to-day difference isn’t the AI — it’s the extension story. Zed extensions are a fundamentally different beast from VS Code extensions, and that shapes what you can do with the editor.
VS Code extensions: full Node.js, full network, full filesystem
A VS Code extension is, mechanically, a Node.js process that VS Code launches and talks to over a JSON-RPC connection. It can:
- Open arbitrary network connections
- Read and write any file the user has access to
- Spawn arbitrary subprocesses
- Use any npm package
- Persist state to its own files
This is enormous flexibility, and it’s why the VS Code extension marketplace has 60k+ extensions covering every conceivable use case. It’s also why VS Code extensions can do unexpected things — track your activity, hijack your terminal, install other extensions, send your code to remote servers.
Cursor inherits this model unchanged. Every VS Code extension runs in Cursor with full Node.js capabilities.
Zed extensions: WebAssembly, sandboxed
A Zed extension is a WebAssembly module. It runs in a sandbox with a fixed API surface. It can:
- Implement language servers (the LSP is the primary extension point)
- Provide syntax highlighting via tree-sitter grammars
- Add themes
- Add slash commands for the assistant
- Add context providers for the assistant
It cannot, by default:
- Open arbitrary network connections
- Spawn arbitrary subprocesses
- Read or write files outside the project
- Use arbitrary system libraries
This is a much narrower API. It’s also a much safer one.
Why Zed made this choice
Zed’s team made the WASM decision early, and the rationale shows up in the architecture: extensions should not be able to slow down the editor, leak the user’s data, or crash the host process.
WASM gives them:
- Process isolation — extension crashes don’t take down the editor
- No I/O surprises — extensions can’t suddenly start network requests during typing
- Predictable performance — WASM execution time is bounded; an infinite loop in an extension can be killed without killing Zed
- Cross-platform parity — the same extension binary runs on Mac, Linux, and (eventually) Windows
The cost: most VS Code extensions can’t be ported to Zed without significant rework. The marketplace is much smaller as a result.
What this means in practice
For language support, Zed’s model works. Most language servers (rust-analyzer, gopls, ruby-lsp, basedpyright, etc.) are external binaries that Zed launches via the LSP protocol. The extension is a thin wrapper. Zed has good language support for the major languages because the heavy lifting was already done by the LSP ecosystem.
For tooling that’s specific to a niche workflow, Zed’s model is limiting. There’s no equivalent to VS Code’s “GitLens” extension that adds a 20-feature suite around git. There’s no equivalent to “REST Client” that turns your editor into Postman. There’s no equivalent to the dozens of language-specific debuggers that VS Code ships.
Some of these gaps are filled by Zed’s built-ins (git is integrated, debugging is being added). Most aren’t.
The AI extension story
Where Zed’s model becomes interesting: AI extensions are first-class. Zed ships its assistant panel with model selection across Anthropic, OpenAI, Google, and (via Ollama) local models. The slash commands and context providers extension surfaces let third parties extend the assistant.
This is more capable for AI-specific use cases than VS Code’s extension model, where every AI tool reinvents its own UI on top of VS Code’s panels and notifications. Cursor essentially had to fork VS Code to integrate AI deeply, because VS Code’s extension API didn’t support what they needed.
Zed’s bet: the next generation of editor extensions will be AI-shaped, and a sandboxed WASM model is fine for that — language servers + AI hooks cover most of what people want.
What I miss when using Zed
Coming from VS Code/Cursor, three things hit me regularly:
No “Edit and Continue” debugging in some languages. VS Code’s extension ecosystem fills the gaps in language-specific debugging. Zed’s debugger is improving but covers fewer languages with less depth.
No browser-side tooling. The “Live Preview” extensions, the WebView-based UIs for visual editing — these don’t exist in Zed. If you need them, you don’t switch to Zed.
Missing one-off plugins. Every codebase I work in has one or two random extensions that I rely on without thinking — a Mermaid preview, a Make file syntax highlighter, a specific company’s internal extension. The probability that all of them are available in Zed is low.
What I appreciate when using Zed
Startup time. Zed starts in roughly half a second. Cursor takes 3-5 seconds. The compounding effect over a year of opening projects is meaningful.
Memory usage. Zed at idle holds about 200MB. VS Code with my normal extension set holds 1.2GB. On laptops without much memory headroom, this matters.
No extension surprises. I don’t worry that an extension I installed two years ago is silently sending my code somewhere. The sandbox is real; the API surface is finite; the surface area for misbehavior is small.
The pragmatic take
If your work depends on a specific niche tool that exists only as a VS Code extension, you’re probably staying on VS Code or Cursor. The migration cost is too high for one tool.
If your work is mostly editing code in well-supported languages and using AI assistance, Zed’s model is competitive and the editor is faster. The tradeoff is fewer extensions but a more cohesive base experience.
The architectural choice — WASM sandboxed extensions vs full Node.js extensions — isn’t a small detail. It changes what kinds of tools the ecosystem produces and what kinds of risks you’re carrying. For a long-term editor choice, it’s worth understanding which model you’re choosing.
