Zed extension: hosting Orbit in Zed and publishing to the extension registry

[imshaikot]

Hosting Orbit in Zed and publishing it to Zed's extension registry, in steps that leave the current VS Code development and release flow untouched.

What Zed allows (checked September 2026)

• Extensions are Rust compiled to wasm32-wasip2; they cannot host a web page. The registry (zed-industries/extensions) accepts language, language-server/debugger, theme, snippet and MCP server extensions; agent-server and slash-command extensions are deprecated and no longer accepted. An MCP server extension may not bundle its server: it downloads it (npm, in our case).
• Zed starts the server as an MCP process over stdio with the project root as its working directory, so the Orbit host for Zed is a Node package: it serves the 3D page on localhost, runs Claude Code as the VS Code extension does, and answers graph questions to Zed's agent as MCP tools.
• Publishing is a PR to the registry that adds a git submodule pointing at the extension's repository and an entry in extensions.toml; an extension may live in a subdirectory (path = "apps/zed"), with its LICENSE inside that directory. Updates bump the submodule and the version. Rules: HTTPS submodule URL, the commit on a branch, one extension per PR, at most three open PRs, reply to review within three weeks.

How this stays out of the way

• yarn build, yarn typecheck, yarn boundaries, yarn harness and yarn smoke never need Rust: apps/zed has check and package targets, no build.
• Rust and the zed-extension CLI live in one CI job that runs only when apps/zed changes.
• Zed gets its own release group and tag (zed-v<version>); the VS Code (v*) and npm (*-v*) jobs keep working as they do, with one exclusion.
• The submodule lives in our fork of the registry, never in this repository.
• The registry PR is opened by a script that is skipped without its token, so a release never blocks on Zed.
• The server is an npm package with its own releases (server-v*); the extension pins the version it installs.

Steps, in order

• Core: move the controller's editor-agnostic half into @orbit-code/core #1 Core: move the controller's editor-agnostic half into @orbit-code/core
• Server: apps/server, the local Orbit host, published to npm as @orbit-code/server #2 Server: apps/server, the local Orbit host, published to npm as @orbit-code/server
• Server: --mcp mode, graph tools and orbit_open for Zed #3 Server: --mcp mode, graph tools and orbit_open for Zed
• Zed: apps/zed, an MCP context-server extension that installs @orbit-code/server #4 Zed: apps/zed, an MCP context-server extension that installs @orbit-code/server
• Release: a zed release group, TOML version actions and zed-v tags #5 Release: a zed release group, TOML version actions and zed-v tags
• CI: build and package apps/zed with Rust and the zed-extension CLI #6 CI: build and package apps/zed with Rust and the zed-extension CLI
• Release: submit.mjs opens the PR to zed-industries/extensions on a zed-v tag #7 Release: submit.mjs opens the PR to zed-industries/extensions on a zed-v tag
• Zed: first submission (fork, token, manual test in Zed, review) #8 Zed: first submission (fork, token, manual test in Zed, review)

#4, #5, #6 and #7 can proceed in parallel with #2 and #3; only #8 needs all of them.

References

• Zed: developing extensions, MCP server extensions, publishing guide, prerequisites, license requirements, updating (zed.dev/docs/extensions/…)
• zed_extension_api 0.7.0: context_server_command, npm_install_package, node_binary_path, ContextServerSettings::for_project
• Reference extension: zed-extensions/postgres-context-server
• Registry CI: zed-industries/extensions/.github/workflows/ci.yml (Rust 1.90, wasm32-wasip2, pinned zed-extension CLI, pnpm package-extensions, pnpm sort-extensions)
• The monorepo skill, "Adding an editor" and "Releases"