Onboarding: zed-industries/zed

Generated by RepoPilot · 2026-05-05 · Source

Verdict

WAIT — Mixed signals — read the receipts

• Last commit today
• 5 active contributors
• Distributed ownership (top contributor 26%)
• Other licensed
• CI configured
• ⚠ Small team — 5 top contributors
• ⚠ Non-standard license (Other) — review terms
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

TL;DR

Zed is a high-performance, GPU-accelerated, multiplayer code editor written entirely in Rust, built by the creators of Atom and Tree-sitter. It uses a custom UI framework (GPUI) that renders directly via Metal (macOS), WGSL/HLSL (GPU shaders), bypassing Electron entirely for near-native performance. Core capabilities include real-time collaborative editing (like Google Docs for code), deep Tree-sitter-based syntax/AST support, and integrated AI coding agents with support for Anthropic, Deepseek, Bedrock, Copilot, and Codestral. Monorepo with 80+ Rust crates under crates/, each scoped to a single concern (e.g. crates/editor for the core editor, crates/gpui for the GPU UI framework, crates/collab for multiplayer server logic, crates/agent for AI agent runtime). Shader code lives in WGSL/HLSL/Metal files within the gpui crate; cloud/collab infrastructure is in crates/collab and crates/client. Cargo workspace is defined at the root Cargo.toml.

Who it's for

Professional software engineers who find VS Code/Electron-based editors too slow or memory-hungry, and teams wanting built-in real-time multiplayer editing without plugins. Contributors are systems programmers comfortable with Rust who want to work on editor infrastructure, GPU rendering pipelines, LSP integrations, AI agent tooling, or Tree-sitter grammars.

Maturity & risk

Zed is production-ready and actively maintained by a well-funded company (Zed Industries, Inc.) with a full engineering team. CI runs via GitHub Actions (.github/workflows/run_tests.yml), with separate test runners for macOS, Linux, and Windows. The codebase has 80+ crates, comprehensive test infrastructure via .config/nextest.toml, and active multi-platform release workflows including staging bumps and patch versioning.

The primary risk is the custom GPUI framework — it is not a standard toolkit, so contributors must learn Zed-specific UI primitives with little external documentation. The codebase has 80+ internal crates with heavy interdependencies, making onboarding slow. Platform support is uneven: Web is explicitly unimplemented (tracking issue #5396), and Windows/Linux support is newer and potentially less stable than macOS.

Active areas of work

Active development is visible in the workflow files: .github/workflows/background_agent_mvp.yml suggests an MVP for background AI agents is being built. The presence of crates/dap, crates/dap_adapters, crates/debugger_ui, and crates/debugger_tools indicates a debugger (DAP protocol) is being actively integrated. crates/acp_thread and crates/acp_tools suggest a new agent communication protocol is in progress. Staging bump workflows (bump_collab_staging.yml) imply frequent collab server deployments.

Get running

macOS (primary platform)

git clone https://github.com/zed-industries/zed.git cd zed

Install Rust via rustup if not present

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Install system deps (macOS)

brew install cmake

Build and run

cargo run --release -p zed

For development/debug build

cargo run -p zed

See docs/src/development/macos.md for full prerequisites

Daily commands: cargo run -p zed # debug build cargo run --release -p zed # release build cargo nextest run # run all tests (requires cargo-nextest) cargo run -p collab # run collab server locally

Map of the codebase

• Cargo.toml — Workspace root manifest defining all crates, shared dependencies, and feature flags — the authoritative map of the entire codebase structure.
• CONTRIBUTING.md — Required reading for all contributors: build instructions, code style, PR process, and architectural conventions specific to Zed.
• AGENTS.md — Defines the agentic AI subsystem architecture and conventions that underpin Zed's AI-assisted coding features.
• CLAUDE.md — Documents the Claude AI integration layer and prompt conventions used across agent and assistant crates.
• .cargo/config.toml — Cargo build configuration controlling linker flags, target triples, and build profiles that affect every crate compilation.
• .github/workflows/run_tests.yml — Primary CI workflow — defines the test matrix, required checks, and merge gates every PR must pass.
• .zed/settings.json — Canonical in-repo Zed settings used as the live reference for default configuration shape and editor behavior.

How to make changes

Add a new LLM provider crate

1. Create a new crate directory under crates/ (e.g. crates/my_provider) with Cargo.toml declaring it as a workspace member following the pattern of crates/anthropic or crates/bedrock. (Cargo.toml)
2. Implement the provider trait (matching the interface used by crates/cloud_llm_client) in crates/my_provider/src/lib.rs, handling streaming responses and tool-use callbacks. (Cargo.toml)
3. Register the new provider in the agent settings schema inside crates/agent_settings so it appears in the model picker UI. (Cargo.toml)
4. Add integration test coverage and wire up the provider in .github/workflows/run_tests.yml if special env vars are needed for CI. (.github/workflows/run_tests.yml)

Add a new collab server API endpoint

1. Define the new request/response types in crates/cloud_api_types following existing protobuf or serde patterns. (Cargo.toml)
2. Implement the handler in the crates/collab crate, registering the route in the router setup matching existing endpoint patterns. (Cargo.toml)
3. Add client-side call in crates/client using the cloud_api_client abstraction so the editor can invoke the new endpoint. (Cargo.toml)
4. Update the collab Dockerfile if new environment variables or secrets are required, and add a deploy step to .github/workflows/deploy_collab.yml. (.github/workflows/deploy_collab.yml)

Add a new Zed extension

1. Scaffold the extension crate under crates/ with a Cargo.toml following the extension manifest conventions documented in CONTRIBUTING.md. (CONTRIBUTING.md)
2. Add the extension to the workspace members list in the root Cargo.toml so it participates in cargo build and test. (Cargo.toml)
3. Write extension tests and ensure they pass via the extension-specific CI workflow. (.github/workflows/extension_tests.yml)
4. Trigger a version bump PR using the extension_bump workflow when ready for release. (.github/workflows/extension_bump.yml)

Add a new GitHub Actions CI check

1. Create a new workflow file under .github/workflows/ referencing the shared run_tests action for consistent environment setup. (.github/actions/run_tests/action.yml)
2. Add any required style or lint steps by composing the check_style action already used in other workflows. (.github/actions/check_style/action.yml)
3. Register the new check as a required status check in the branch protection rules and reference it from the PR labeler if label-gated. (.github/workflows/pr_labeler.yml)

Why these technologies

• Rust — Provides the memory safety and performance necessary for a low-latency editor handling large files, concurrent LSP sessions, and real-time CRDT-based collaboration without a GC pause.
• GPUI (custom GPU UI framework) — Off-the-shelf UI toolkits could not meet Zed's 120fps rendering target; GPUI renders directly via Metal/WebGPU with a retained-mode scene graph owned by the Zed team.
• Tree-sitter — Provides incremental, error-tolerant parsing for syntax highlighting and code navigation across hundreds of languages with sub-millisecond reparse times.
• CRDTs (custom clock crate) — Enables conflict-free real-time collaborative editing without operational transform complexity, inspired by the authors' prior work on Atom Teletype.
• Cloudflare Workers — Used for docs proxying and open-source asset CDN to minimise latency for global users without managing additional server infrastructure.

Trade-offs already made

• Custom GPU UI framework (GPUI) instead of egui/tauri/electron

  • Why: Needed full control over rendering pipeline, event loop, and async model to hit 120fps and integrate tightly with Rust async.
  • Consequence: All contributors must learn GPUI's component model; no ecosystem of off-the-shelf widgets is available.

• Monorepo with 60+ workspace crates

  • Why: Enforces clear dependency boundaries and allows incremental compilation, with each crate owning a single responsibility.
  • Consequence: Cold build times are long; CI must cache aggressively, and workspace dependency upgrades require touching many Cargo.toml files.

• Collab server as a separate deployed service (Dockerfile-collab)

  • Why: Isolates multiplayer state from the local editor process, enabling horizontal scaling and independent deployments.
  • Consequence: Local development requires running the collab server separately; network partitions affect collaboration but not solo editing.

• undefined

  • Why: undefined
  • Consequence: undefined

Traps & gotchas

1. GPUI is entirely custom — do not expect Qt, GTK, or web-component mental models to transfer. 2) macOS is the primary dev target; Metal shaders in crates/gpui will not compile on Linux/Windows without the WGSL/HLSL shader paths. 3) The collab server requires a PostgreSQL database and specific environment variables to run locally — check crates/collab for .env requirements. 4) cargo-about must be satisfied for CI to pass on license checks; adding any new crate dependency requires updating script/licenses/zed-licenses.toml. 5) Extension WASM compilation requires a specific wasm32 target: rustup target add wasm32-wasi.

Architecture

Concepts to learn

• CRDT (Conflict-free Replicated Data Type) — Zed's multiplayer real-time collaborative editing (crates/collab, crates/client) uses CRDTs to merge concurrent text edits from multiple users without a locking server
• Tree-sitter incremental parsing — Zed uses Tree-sitter for all syntax highlighting, code folding, and structural navigation — understanding incremental AST updates is essential for language support work
• WGSL (WebGPU Shading Language) — Zed's cross-platform GPU rendering path uses WGSL shaders (alongside Metal and HLSL) inside crates/gpui — required knowledge for any rendering work on Linux/Windows
• DAP (Debug Adapter Protocol) — crates/dap and crates/debugger_ui implement DAP, the LSP-equivalent protocol for debuggers — understanding it is needed to contribute to Zed's in-progress debugger feature
• WASM-based plugin sandboxing — Zed extensions run as WebAssembly modules (crates/extension_host) for isolation and portability — the wasm32-wasi target and WASI interface are central to the extension system
• Rope data structure — High-performance text editors use ropes (not Strings) to efficiently handle large files and frequent insertions/deletions — the buffer representation in crates/editor is built on this
• LSP (Language Server Protocol) — Zed's code intelligence (completions, diagnostics, go-to-definition) is driven by LSP — multiple crates wrap LSP client logic and extension authors configure LSP servers

Related repos

• microsoft/vscode — The dominant alternative code editor that Zed directly competes with — Electron-based vs Zed's native Rust/GPU approach
• helix-editor/helix — Another modern, terminal-based Rust code editor with Tree-sitter integration — overlapping tech stack and target audience
• tree-sitter/tree-sitter — The incremental parsing library that powers Zed's syntax highlighting and code intelligence — co-created by Zed's founders
• zed-industries/extensions — The companion repository containing first-party and community Zed extensions built against crates/extension_api
• atom/atom — Predecessor project from the same founders — Zed was built as a ground-up rewrite addressing Electron performance limitations of Atom

PR ideas

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add integration tests for the DAP (Debug Adapter Protocol) extension host in crates/dap and crates/debug_adapter_extension

The repo has both a crates/dap and crates/debug_adapter_extension crate, plus crates/dap_adapters and crates/debugger_ui. Debugger support in editors is complex and error-prone, yet the file listing shows no dedicated test workflows for DAP integration. Adding unit and integration tests for adapter lifecycle (attach, launch, breakpoints, step-over) would catch regressions early and make it safer for contributors to extend DAP support. This is high-value because DAP is a relatively new feature in Zed and likely has thin test coverage.

• [ ] Audit existing tests in crates/dap/src/ and crates/debug_adapter_extension/src/ to identify untested public APIs
• [ ] Add unit tests in crates/dap/src/ covering adapter session lifecycle: initialization handshake, breakpoint set/clear, and event dispatching
• [ ] Add unit tests in crates/dap_adapters/src/ for at least two concrete adapter implementations (e.g., the bundled ones) verifying correct capability negotiation
• [ ] Add an integration test in crates/debugger_ui/ that simulates a full launch→hit-breakpoint→continue flow using a mock DAP server
• [ ] Ensure the new tests run under the existing .github/actions/run_tests workflow by verifying the crate names appear in the workspace member list in Cargo.toml

Add a GitHub Actions workflow specifically for extension API compatibility testing (crates/extension_api and crates/extension_host)

The repo has .github/workflows/extension_tests.yml and extension_bump.yml, but these appear to focus on bumping versions and running general tests rather than explicitly verifying that the public extension_api surface remains backward-compatible with existing extensions. Because crates/extension_api is a stable public contract consumed by third-party extension authors, a dedicated CI workflow that compiles a set of representative extension fixtures against the current extension_api crate would catch breaking changes before they ship. This is directly actionable and specific to the extension ecosystem Zed is building.

• [ ] Create .github/workflows/extension_api_compat.yml that triggers on any change to crates/extension_api/** or crates/extension_host/**
• [ ] Add a small tests/extension_api_compat/ directory containing two or three minimal Rust extension fixtures that exercise the most commonly used traits and types from crates/extension_api
• [ ] In the workflow, run cargo build for each fixture crate against the workspace's current extension_api to confirm no compilation errors
• [ ] Add a cargo semver-checks step (or equivalent) to surface any semver-breaking changes in crates/extension_api automatically
• [ ] Document the workflow purpose in .github/workflows/extension_api_compat.yml with inline comments explaining what 'compatibility' means in this context

Split the monolithic crates/editor crate by extracting edit-prediction UI glue into crates/edit_prediction_ui, reducing coupling

The file listing reveals that edit-prediction functionality is already partially split across crates/edit_prediction, crates/edit_prediction_cli, crates/edit_prediction_context, crates/edit_prediction_metrics, crates/edit_prediction_types, and crates/edit_prediction_ui. However, crates/editor is historically one of the largest crates in Zed. Any UI rendering or event-handling code in crates/editor/src/ that is solely responsible for bridging the editor to edit_prediction_ui should live in edit_prediction_ui instead, reducing crates/editor's compile surface and making both crates easier to test in isolation. This follows the repo's own pattern of

Good first issues

1. Add missing nextest unit tests for crates/csv_preview — the CSV preview feature appears new and likely has thin test coverage based on its standalone crate structure. 2) Add documentation comments to the public types in crates/extension_api/src/lib.rs — this is the external developer-facing API and missing rustdoc would frustrate extension authors. 3) Improve error messages in crates/askpass — the askpass credential helper crate is small and isolated, making it a low-risk place to add user-facing error context with anyhow/thiserror patterns already used elsewhere.

Top contributors

• @bennetbo — 8 commits
• @Veykril — 7 commits
• @maxdeviant — 6 commits
• @Anthony-Eid — 5 commits
• @osyvokon — 5 commits

Recent commits

• 2c5fcfc — client: Pass x-zed-system-id header in get_authenticated_user() (#55688) (tomhoule)
• 07e57bb — zed: Do not upload crashes that lack an associated release (#55605) (Veykril)
• fac5321 — ci: Create releases with the Zed Zippy identity (#55649) (MrSubidubi)
• b5abd9d — Fix micromamba powershell activation (#55643) (adament)
• 149cd4e — git_graph: Add remote support for search operations (#55167) (Anthony-Eid)
• 8aedcbf — debugger_ui: Fix debugger tab drop crash (#55667) (Veykril)
• c3a3eea — Remove Flatpak warning now that sandboxing is reverted (#55673) (ConradIrwin)
• 42f9420 — Fix handling of git repositories with an external git directory (#55402) (maxbrunsfeld)
• 8f2ab51 — agent: Refactor edit file tool state handling (#55663) (bennetbo)
• 11371e6 — Fix panic in multi_buffer::Anchor::is_valid (#55644) (cole-miller)

Security observations

• High · Cloudflare Worker Proxy Potential Security Misconfiguration — .cloudflare/docs-proxy/src/worker.js, .cloudflare/open-source-website-assets/src/worker.js. The Cloudflare Worker scripts (.cloudflare/docs-proxy/src/worker.js and .cloudflare/open-source-website-assets/src/worker.js) act as reverse proxies. Without reviewing the actual content, worker proxy configurations are commonly vulnerable to open redirect, header injection, or insufficient origin validation, allowing attackers to proxy arbitrary requests or bypass access controls. Fix: Ensure strict origin allowlisting is enforced in Cloudflare Worker logic. Validate and sanitize all request headers before forwarding. Ensure CORS headers are restrictively configured and no open-redirect paths exist.
• High · Potential Hardcoded Credentials in Cargo Configuration Files — .cargo/collab-config.toml, .cargo/ci-config.toml. The presence of .cargo/collab-config.toml and .cargo/ci-config.toml suggests environment-specific configuration files that may contain API keys, tokens, or secrets used for CI/CD pipelines or collab server authentication. If these files are committed to version control without redaction, sensitive credentials could be exposed. Fix: Audit these configuration files for any hardcoded secrets, tokens, or credentials. Move all sensitive values to environment variables or a secrets manager (e.g., GitHub Actions secrets, HashiCorp Vault). Ensure these files are listed in .gitignore if they contain sensitive data.
• High · SQL Injection Risk in collab and db Crates — crates/collab, crates/db. The codebase includes both a 'collab' crate (likely a server-side component handling real-time collaboration) and a 'db' crate (database abstraction). Server-side Rust applications interfacing with SQL databases may be vulnerable to SQL injection if raw query construction is used without parameterized queries or ORM safe abstractions. The presence of a database crate alongside a networked collab server increases this attack surface. Fix: Ensure all database queries use parameterized statements or a safe ORM (e.g., sqlx with compile-time checked queries, Diesel). Audit all raw SQL string construction. Run SAST tools specifically targeting SQL query patterns.
• High · Supply Chain Risk from Large Dependency Surface — Cargo.toml (workspace). The workspace contains an extremely large number of crates (70+ internal crates) and likely hundreds of transitive external dependencies. This significantly increases the supply chain attack surface. Crates such as 'anthropic', 'bedrock', 'copilot', 'copilot_chat', 'deepseek', 'codestral', 'cloud_llm_client', and others interface with external AI/LLM APIs, introducing risk from compromised upstream packages or malicious dependency updates. Fix: Regularly audit dependencies with 'cargo audit' against the RustSec advisory database. Pin dependency versions with a Cargo.lock file committed to the repository. Use 'cargo deny' for license and vulnerability checking. Consider using cargo-vet or similar supply chain verification tools.
• High · Credential and Secret Handling in AI/LLM Provider Crates — crates/anthropic, crates/bedrock, crates/copilot, crates/copilot_chat, crates/deepseek, crates/codestral, crates/cloud_llm_client, crates/aws_http_client. Multiple crates (anthropic, bedrock, copilot, copilot_chat, deepseek, codestral, cloud_llm_client, aws_http_client) handle API credentials for external AI services. These crates likely process API keys that, if improperly stored (e.g., in plaintext config files, logged to debug output, or exposed via error messages), could lead to credential leakage. Fix: Ensure API keys are stored using the 'credentials_provider' crate abstraction with OS keychain integration. Ensure keys are never logged (even at debug level). Implement key rotation support. Audit error handling to prevent key material from appearing in stack traces or error messages.
• Medium · Extension Host Sandbox Escape Risk — undefined. The presence of 'crates/extension_host', 'crates/extension', 'crates/extension_api', and 'crates/extension_cli' indicates a Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

Where to read next

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

---

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.