Zed — Administrator & Developer Guide

Operational reference for building, packaging, configuring, operating, and extending Zed — the GPU-accelerated, multiplayer code editor written in Rust.

This guide is for administrators, packagers, platform engineers, extension authors, and contributors. For end-user workflows, key bindings, and daily usage, see the User Guide.

Zed is a Cargo workspace with ~200 crates. It ships as a single zed binary plus an auxiliary cli launcher and a separate collab collaboration server. The codebase targets macOS (Metal), Linux (Vulkan/OpenGL via Wayland or X11), and Windows (DirectX/WGPU), all rendered through a custom GPU UI framework called GPUI.

1. Architecture Overview

1.1 System Topology

+------------------- Zed Desktop Process -----------------------+
|                                                               |
|   crates/zed (main entry — crates/zed/src/main.rs)            |
|     |                                                         |
|     v                                                         |
|   crates/workspace     <--- Window/pane/panel management      |
|     |           \                                             |
|     |            +--> crates/editor                           |
|     |            |       |                                    |
|     |            |       v                                    |
|     |            |    crates/language, language_core, lsp     |
|     |            |       |                                    |
|     |            |       v                                    |
|     |            |    crates/project (LSP/DAP/Git store,      |
|     |            |       worktree, task runner)               |
|     |            |                                             |
|     |            +--> crates/terminal + terminal_view         |
|     |            +--> crates/agent_ui  --> crates/agent       |
|     |            +--> crates/debugger_ui --> crates/dap*      |
|     |            +--> crates/git_ui     --> crates/git        |
|     |            +--> crates/collab_ui  --> crates/rpc,       |
|     |                                       channel, call     |
|     |                                                         |
|     v                                                         |
|   crates/gpui (UI framework)                                  |
|     |    \----- crates/gpui_{macos,windows,linux,web,wgpu}    |
|     v                                                         |
|   GPU (Metal / DirectX / WGPU / OpenGL / WASM)                |
+---------------------------------------------------------------+
          |                           |
          | SSH remote protocol       | RPC (protobuf over TLS)
          v                           v
   remote_server (on dev box)    collab.zed.dev (crates/collab)
                                      |   \---> LiveKit (SFU)
                                      v
                                  Postgres

1.2 Binaries in the Workspace

Note

The cli binary is a separate process from the main zed binary. It communicates via ipc-channel to launch or connect to a running Zed instance. On macOS, the CLI is installed as a symlink; on Linux and Windows, it ships alongside the main binary.

1.3 Core Crate Inventory

The ~200 workspace crates break down into several functional layers:

UI Framework Layer

Text Engine Layer

Editor Layer

Language & Intelligence Layer

AI & Agent Layer

AI Provider Crates

Collaboration Layer

Debug & Dev Tools Layer

Extension System Layer

Infrastructure Layer

1.4 Technology Stack

1.5 Event and Data Flow

1. The user triggers an action via keybinding, menu, command palette, or IPC from the CLI.
2. GPUI dispatches the action through the focused element tree and its chain of contexts.
3. Workspace dispatches to the relevant handler: Pane, Editor, or a panel (terminal, agent, git, debugger).
4. For semantic operations, project forwards requests to the relevant subsystem:
   • LSP: JSON-RPC to language server process
   • DAP: JSON over stdio to debug adapter process
   • Git: libgit2 bindings with CLI fallback
   • Remote: Multiplexed SSH connection to remote_server
5. Results update Buffer / MultiBuffer / Project models, which emit events.
6. GPUI re-renders only the subtree affected by the change.

1.6 Concurrency Model

• BackgroundExecutor — thread pool for CPU-bound work (parsing, LSP requests, git scans). Uses rayon with half available parallelism and 10MB thread stacks.
• ForegroundExecutor — single-threaded, tied to the UI thread. Drives GPUI's Futures/Tasks.
• Entity<T> — GPUI's actor-lite primitive (cx.new(|cx| ...)). Entities mutate on the foreground executor only; cross-thread communication goes through channels or spawn-with-cx.update.

Everything is async under the hood. Zed uses its own smol-based runtime with Tokio shims (gpui_tokio) where needed for libraries that require Tokio.

2. System Requirements

2.1 Runtime Requirements (Using Zed)

2.2 Build Requirements (Compiling Zed)

Platform-specific build dependencies:

2.3 Collab Server Requirements

Important

The collab server is a separate binary (crates/collab/src/main.rs) with its own database and LiveKit dependencies. It is NOT required for local-only Zed usage. Self-hosting collab requires PostgreSQL and a LiveKit instance; see compose.yml and livekit.yaml in the repository root.

3. Configuration Reference

3.1 Configuration System Architecture

Zed uses a cascading settings system with three levels of precedence:

Lowest priority                              Highest priority
     |                                            |
     v                                            v
  Default settings  →  User settings  →  Project settings
  (assets/settings/     (~/.config/zed/     (.zed/settings.json)
   default.json)         settings.json)

All settings files use JSONC (JSON with comments). The schema is generated by crates/schema_generator and the full defaults live in assets/settings/default.json.

Keymaps follow a similar cascade:

Default keymaps  →  Base keymap selection  →  User keymap
(assets/keymaps/)    (vim, helix, etc.)       (keymap.json)

3.2 Settings File Locations

Project-local settings: .zed/settings.json in the project root.

3.3 Data Directory Locations

Contents: logs, extensions, languages, themes, database, crash reports.

Important

Settings use JSONC format (JSON with comments and trailing commas). Standard JSON parsers will reject these files. Use the schema_generator binary to produce JSON Schema files for editor validation.

3.4 Editor Settings

3.5 Formatting & Language Settings

Language-specific overrides use the "languages" key:

{
  "languages": {
    "Python": {
      "tab_size": 4,
      "formatter": "language_server",
      "format_on_save": "on"
    },
    "JavaScript": {
      "tab_size": 2,
      "formatter": "prettier"
    }
  }
}

3.6 UI & Appearance Settings

3.7 Terminal Settings

3.8 Project Panel Settings

3.9 Git & Version Control Settings

3.10 Collaboration Settings

3.11 Auto-Update & Telemetry Settings

Tip

On Linux, if Zed was installed via a package manager (apt, pacman, etc.), the auto_update setting may be ignored in favor of the package manager's update mechanism.

3.12 AI & Agent Settings

Agent profiles configure which tools are available and their permission levels:

{
  "agent": {
    "profiles": {
      "write": {
        "tools": {
          "read_file": "allow",
          "edit_file": "confirm",
          "terminal": "confirm",
          "create_directory": "confirm",
          "delete_path": "deny"
        }
      }
    }
  }
}

Tool permission levels: "allow" (no confirmation), "confirm" (ask first), "deny" (blocked). Tools also support regex patterns for path-based allow/deny rules.

3.13 Extension Capabilities

Extensions operate under a capability-based security model. Capabilities must be explicitly granted:

{
  "granted_extension_capabilities": {
    "extension-name": {
      "read_clipboard": true,
      "network_access": true
    }
  }
}

3.14 Vim Mode Settings

3.15 File Handling Settings

Default file scan exclusions:

[
  "**/.git",
  "**/.svn",
  "**/.hg",
  "**/CVS",
  "**/.DS_Store",
  "**/Thumbs.db",
  "**/.classpath",
  "**/.settings",
  "**/.direnv",
  "**/node_modules",
  "**/target"
]

3.16 Task Configuration

Tasks are defined in .zed/tasks.json (project-level) or global tasks configuration:

[
  {
    "label": "cargo test",
    "command": "cargo",
    "args": ["test"],
    "cwd": "$ZED_WORKTREE_ROOT",
    "env": {},
    "use_new_terminal": false,
    "allow_concurrent_runs": false
  }
]

3.17 Project-Local Settings (.zed/settings.json)

Any setting can be overridden at the project level by placing a settings.json file in the .zed/ directory at the project root. Project settings take highest precedence.

// .zed/settings.json
{
  "tab_size": 2,
  "formatter": "prettier",
  "languages": {
    "TypeScript": {
      "tab_size": 2,
      "format_on_save": "on"
    }
  },
  "lsp": {
    "rust-analyzer": {
      "initialization_options": {
        "check": {
          "command": "clippy"
        }
      }
    }
  }
}

4. Deployment & Building

4.1 Cloning the Repository

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

The repository is large (~200 crates, 3,800+ files, ~31M chars of source). Initial clone may take several minutes.

4.2 Building on macOS

Debug build (fastest rebuild):

cargo run

Release build:

cargo run --release

Create a Zed.app bundle:

./script/bundle-mac

This produces target/release/Zed.app. Signing and notarization are handled in CI via ci/ workflows; local bundles are adhoc-signed and will not auto-update.

4.3 Building on Linux

# Install system dependencies
./script/linux

# Debug build
cargo run

# Release build + install to ~/.local/bin/zed
./script/install-linux

Warning

On GCC >= 14, aws-lc-rs can fail to link the remote_server. Set REMOTE_SERVER_TARGET=x86_64-unknown-linux-gnu before running script/install-linux to work around it.

4.4 Building on Windows

Use the developer command prompt (x64 Native Tools Command Prompt for VS 2022):

cargo run
cargo run --release
.\script\bundle-windows.ps1

The MSIX / EXE installer build is orchestrated by script/bundle-windows.ps1.

4.5 Cross-Compilation

The repository includes Docker-based cross-compilation support:

• Dockerfile-cross.dockerignore — Docker ignore file for cross builds
• Dockerfile-distros — Multi-distro testing

4.6 Nix Build

Zed has full Nix support with a flake:

# Enter dev shell
nix develop

# Build
nix build

# Run
nix run

Key Nix files:

• flake.nix — Flake definition
• default.nix — Legacy Nix expression
• nix/ — Nix-specific modules, including nix/livekit-libwebrtc/ for LiveKit native dependency
• nix/dev/ — Development shell configuration
• nix/modules/ — NixOS module definitions

4.7 Flatpak Build

# Build Flatpak
./script/flatpak/build.sh

Flatpak configuration lives in script/flatpak/.

4.8 Building the Collab Server

cargo build --package collab --release

The collab server is also available as a Docker image:

docker build -f Dockerfile-collab -t zed-collab .

Docker Compose configuration for local development:

docker compose up

The compose.yml at the repository root includes PostgreSQL and LiveKit alongside the collab server. Procfile, Procfile.all, and Procfile.web provide process manager configurations for different deployment scenarios.

Tip

For local development, use Procfile.all with a process manager like foreman or overmind to run all services (collab, LiveKit, database) simultaneously.

4.9 cargo-xtask

The tooling/xtask/ crate provides custom build tasks:

cargo xtask --help

Xtask handles CI helpers, workflow generation, and diagnostic utilities.

4.10 Release Channels

Zed has four release channels, defined in crates/release_channel/src:

The active channel affects feature flags, update behavior, telemetry, and server endpoints.

5. Operations

5.1 Auto-Update System

The auto-update system (crates/auto_update) checks for and applies updates automatically. The auto_update_helper binary handles the actual update application (file replacement, restart coordination).

Configuration:

{
  "auto_update": true  // or false to disable
}

Note

On Linux, auto-update may be managed by your system package manager rather than Zed's built-in mechanism. When installed via apt, pacman, or similar, the auto_update setting is typically ignored.

5.2 Database & State Management

Zed uses SQLite (via the custom sqlez crate) in WAL mode for local state:

• Workspace state — open files, pane layout, window positions
• Settings — cached settings and preferences
• Key-value pairs — arbitrary persistent storage
• Trusted worktrees — directories the user has trusted for extension/LSP execution

The migrator crate handles schema migrations. Database files live under the platform-specific data directory.

5.3 Crash Reporting

The crashes crate manages crash handling:

1. A crash_handler process is spawned alongside Zed
2. On crash, minidumps are captured
3. If telemetry.diagnostics is enabled, crash reports are submitted to Zed's servers

Crash reports are stored locally under the data directory regardless of telemetry settings.

5.4 Telemetry

Telemetry events are defined in crates/telemetry_events/src. Two independent toggles control data collection:

Both default to true. Disable with:

{
  "telemetry": {
    "diagnostics": false,
    "metrics": false
  }
}

Note

Telemetry settings take effect immediately without restart. All telemetry data is anonymous and does not include file contents or personally identifiable information.

5.5 Log Files

Zed logs to the platform-specific data directory. The logging system uses zlog (custom logging crate) with configurable levels via zlog_settings.

Access logs from within Zed: Command Palette > "zed: open log file".

5.6 Collab Server Operations

The collab server (crates/collab) is a standalone Rust binary that requires:

1. PostgreSQL 14+ — stores users, channels, rooms, projects
2. LiveKit 1.6+ — handles WebRTC audio/video SFU

Kubernetes deployment manifests live in crates/collab/k8s/environments/. The collab server API is defined in crates/collab/src/api/.

5.7 Remote Development Operations

The remote development stack consists of:

• remote_server — runs on the remote host, provides headless Zed functionality
• remote_connection — SSH connection management on the client side
• remote — remote protocol coordination
• dev_container — Dev container support (Docker-based development environments)
• askpass — SSH password/passphrase prompting

The remote server is deployed to the target machine over SSH and communicates back through an SSH tunnel. No additional ports need to be opened.

5.8 Extension Management

Extensions are WASM-based and managed through the extension UI or CLI:

# Package an extension
cargo run --package extension_cli -- package ./my-extension

# Publish an extension
cargo run --package extension_cli -- publish ./my-extension

Extensions can provide:

• Languages (grammar, highlights, injections)
• Themes
• Language servers
• Slash commands (for the agent)
• Context servers (MCP)
• Debug adapters

The extension API is defined via WIT (WebAssembly Interface Types) in crates/extension_api/wit/.

Tip

To test an extension locally, place it in the extensions/ directory at the repository root. Built-in extensions like html, glsl, proto, and workflows live there and serve as reference implementations.

6. Performance

6.1 Rendering Pipeline

GPUI renders the entire UI on the GPU. The rendering pipeline:

1. Layout — flexbox-like layout engine computes element positions
2. Paint — elements emit draw commands (quads, glyphs, paths, shadows)
3. Composite — draw commands are batched and submitted to the GPU via wgpu

The renderer targets 120fps on capable hardware. Frame pacing is tied to the display's refresh rate.

6.2 Text Engine Performance

The text engine uses two custom data structures optimized for editor workloads:

• Rope (crates/rope) — a balanced tree of text chunks. Provides O(log n) insert, delete, and index operations. Enables efficient editing of multi-gigabyte files.
• Sum Tree (crates/sum_tree) — a B-tree that maintains running aggregates (line counts, byte offsets, etc.). Powers the display map, fold state, and diagnostics overlay.

6.3 Thread Pool Configuration

Zed uses rayon with the following configuration:

• Thread count: half of available parallelism (e.g., 8 threads on a 16-core machine)
• Stack size: 10MB per thread

This balances responsiveness (leaving cores for the OS and GPU) with throughput for parallel operations like project-wide search and multi-file formatting.

6.4 Memory Allocator

Release builds use mimalloc as the global allocator, which provides better performance characteristics than the system allocator for Zed's allocation patterns (many small, short-lived allocations from the UI framework).

6.5 Performance Profiling

Benchmark crates:

• crates/worktree_benchmarks — file watching performance
• crates/project_benchmarks — project operations performance
• crates/fs_benchmarks — filesystem operation performance

6.6 Performance-Relevant Settings

7. Security

7.1 Extension Security Model

Extensions run in a sandboxed WASM environment with capability-based security:

• Extensions have NO filesystem access by default
• Network access, clipboard access, and other capabilities must be explicitly granted via granted_extension_capabilities
• The WIT interface (crates/extension_api/wit/) defines the exact API surface available to extensions
• Extensions cannot access arbitrary memory or execute native code

{
  "granted_extension_capabilities": {
    "untrusted-extension": {}  // No capabilities granted
  }
}

Warning

The granted_extension_capabilities setting controls what extensions can do. Review capability requests carefully before granting them. An extension with network_access can exfiltrate data from files it processes.

7.2 Agent Tool Permissions

The agent's tool system uses a three-tier permission model:

Tools support regex-based path patterns for granular control:

{
  "agent": {
    "profiles": {
      "safe": {
        "tools": {
          "read_file": {
            "allow": ["src/**", "docs/**"],
            "deny": ["**/.env", "**/secrets/**"]
          },
          "edit_file": "confirm",
          "terminal": "deny",
          "delete_path": "deny"
        }
      }
    }
  }
}

Available agent tools: copy_path, create_directory, delete_path, diagnostics, edit_file, fetch, list_directory, move_path, now, find_path, read_file, restore_file_from_disk, save_file, open, grep, spawn_agent, terminal, thinking, update_plan, search_web.

7.3 Trusted Worktrees

When opening a project for the first time, Zed may prompt to trust the worktree. Trusted worktrees are stored in the local SQLite database. Trusting a worktree allows:

• Language server execution
• Task execution
• Extension activation for that project

7.4 SSH & Remote Security

Remote development uses standard SSH for transport:

• Authentication via SSH keys or the askpass crate for interactive password entry
• All traffic is tunneled through the SSH connection
• No additional ports are opened on the remote host
• The remote_server binary runs with the permissions of the SSH user

7.5 Credential Management

The credentials_provider and zed_credentials_provider crates manage sensitive credentials:

• API keys for AI providers
• Authentication tokens for Zed's cloud services
• OAuth tokens for collaboration

Credentials are stored in the platform's native keychain (Keychain on macOS, Secret Service on Linux, Credential Manager on Windows).

Caution

AI provider API keys configured in settings.json are stored in plain text on disk. For production environments, prefer OAuth-based authentication or environment variables over inline API keys.

7.6 Network Connections

Zed makes outgoing connections to:

8. Developer Internals

8.1 GPUI Framework Architecture

GPUI is Zed's custom, GPU-accelerated UI framework. Key concepts:

Entity System

// Create an entity (actor-lite pattern)
let entity = cx.new(|cx| MyModel::new(cx));

// Read entity state
entity.read(cx);

// Update entity state (foreground executor only)
entity.update(cx, |model, cx| {
    model.do_something(cx);
});

Entities mutate only on the foreground executor. Cross-thread communication uses channels or spawn-with-cx.update.

Element Tree

GPUI uses a retained element tree with immediate-mode-style rendering:

1. render() method returns an element tree description
2. GPUI diffs against the previous tree
3. Only changed subtrees are re-laid-out and re-painted

Actions

Actions are the primary dispatch mechanism:

#[derive(Clone, PartialEq, Action)]
struct MyAction;

// Register handler
cx.on_action(|&MyAction, cx| { /* ... */ });

Actions propagate up the element tree (bubbling) until handled.

8.2 Settings Framework

The settings system (crates/settings) uses a trait-based approach:

#[derive(Deserialize, Default)]
struct MySettings {
    #[serde(default)]
    option_a: bool,
}

impl Settings for MySettings {
    const KEY: Option<&'static str> = Some("my_settings");
    // ...
}

Settings are registered globally and resolved through the cascade (defaults -> user -> project). The settings_macros crate provides derive macros for common patterns.

8.3 Language Server Integration

The LSP integration spans several crates:

1. lsp — JSON-RPC transport and LSP protocol types
2. language — buffer integration, highlighting, diagnostics
3. project/src/lsp_store — project-level LSP lifecycle management

LSP servers are configured per-language. Custom initialization options can be passed via settings:

{
  "lsp": {
    "rust-analyzer": {
      "initialization_options": {
        "cargo": {
          "features": "all"
        },
        "check": {
          "command": "clippy"
        }
      }
    }
  }
}

8.4 Debug Adapter Protocol Integration

The DAP stack mirrors LSP:

1. dap — DAP transport (JSON over stdio)
2. dap_adapters — per-adapter configurations (CodeLLDB, debugpy, JS debug, etc.)
3. debugger_ui — UI panels (variables, call stack, breakpoints)
4. debug_adapter_extension — DAP support via the extension system

Adapters can be auto-installed when a debug session starts.

8.5 Tree-sitter Integration

Zed uses tree-sitter for:

• Syntax highlighting
• Code folding
• Bracket matching
• Outline/symbols
• Indentation computation
• Injection queries (embedded languages)

Grammar management lives in crates/grammars. Language configurations (highlights, injections, textobjects) are in crates/languages and extensions.

8.6 Protobuf RPC Layer

The collaboration and remote protocols use protobuf:

• proto — .proto definitions in crates/proto/proto/, generated via prost
• rpc — multiplexed connection, message routing, peer management

The RPC layer supports both collaboration (client-server via collab) and remote development (peer-to-peer via SSH tunnel).

8.7 Edit Prediction System

The edit prediction system provides AI-powered inline completions:

1. edit_prediction — runtime coordination, accept/reject logic
2. edit_prediction_context — gathers surrounding code context
3. zeta_prompt — builds prompts for the prediction model
4. edit_prediction_metrics — tracks prediction quality
5. edit_prediction_ui — renders ghost text overlay
6. edit_prediction_cli — offline evaluation tooling

8.8 WASM Extension Runtime

Extensions are compiled to WASM and run in the extension_host:

1. Extension author writes Rust (or any language targeting WASM)
2. The extension_api crate provides the guest-side API
3. WIT definitions (crates/extension_api/wit/) describe the interface
4. The extension_host instantiates WASM modules via wasmtime
5. Capability gates control access to host functionality

8.9 Crate Dependency Graph (Simplified)

zed (binary)
├── workspace
│   ├── editor
│   │   ├── language, language_core
│   │   ├── lsp
│   │   ├── multi_buffer
│   │   │   ├── text
│   │   │   │   ├── rope
│   │   │   │   └── sum_tree
│   │   │   └── buffer_diff
│   │   └── project
│   │       ├── worktree → fs
│   │       ├── git
│   │       ├── dap
│   │       └── remote_connection
│   ├── sidebar
│   │   ├── agent_ui → agent → language_model → provider crates
│   │   ├── git_ui
│   │   ├── debugger_ui
│   │   └── project_panel
│   └── terminal_view → terminal
├── gpui
│   ├── gpui_{macos,linux,windows,web}
│   └── gpui_wgpu
├── extension_host → extension_api
├── settings
├── theme
├── db → sqlez
└── auto_update

8.10 Key Data Structures

9. Integration Points

9.1 Language Server Protocol (LSP)

Zed acts as an LSP client. Language servers are managed per-project by the lsp_store in the project crate. Configuration per-server is done via the lsp key in settings:

{
  "lsp": {
    "server-name": {
      "initialization_options": { /* server-specific */ },
      "settings": { /* server-specific workspace settings */ }
    }
  }
}

9.2 Debug Adapter Protocol (DAP)

Zed acts as a DAP client. Adapter configurations live in crates/dap_adapters/src. Supported adapters include CodeLLDB, debugpy, and others via the extension system.

9.3 AI Providers

Each AI provider has its own crate implementing the LanguageModel trait from crates/language_model. Provider configuration is done via settings:

{
  "language_models": {
    "anthropic": {
      "api_key": "...",
      "default_model": "claude-sonnet-4-20250514"
    },
    "ollama": {
      "api_url": "http://localhost:11434"
    },
    "openai": {
      "api_key": "...",
      "default_model": "gpt-4o"
    }
  }
}

Full provider list: Anthropic, OpenAI, Ollama, LM Studio, Mistral, DeepSeek, Google AI, OpenRouter, AWS Bedrock, GitHub Copilot, xAI, Codestral, Vercel, Zed Cloud.

9.4 MCP (Model Context Protocol)

The agent system supports MCP context servers via crates/context_server. Context servers provide additional context to agent conversations (documentation, codebase knowledge, external data).

9.5 Git Integration

Git support is provided through crates/git with libgit2 bindings and CLI fallback:

• Inline blame (git.inline_blame)
• Gutter diff indicators
• Git status in project panel and tabs
• Full Git UI panel (crates/git_ui)
• Git graph visualization (crates/git_graph)
• Hosting provider integration (crates/git_hosting_providers) for GitHub, GitLab, Bitbucket, etc.

9.6 Jupyter / REPL

The repl crate (crates/repl) provides Jupyter kernel integration for interactive code execution. Supports inline output rendering.

9.7 IPC (CLI to GUI)

The cli binary communicates with the main zed process via ipc-channel:

• Launch new Zed instance or connect to running one
• Open files/directories
• --wait flag blocks the CLI until the file is closed in Zed

9.8 Audio & Collaboration

The collaboration stack uses:

• LiveKit — WebRTC SFU for audio/video
• denoise — noise suppression using bundled ML models (in crates/denoise/models/)
• call — call management
• channel — text and voice channels

9.9 Web Search

The web_search and web_search_providers crates provide web search integration for the agent, allowing it to search the web for relevant information during conversations.

9.10 Troubleshooting

Common Build Issues

Common Runtime Issues

Warning

If Zed crashes on startup, check for corrupted state by renaming the data directory (see Section 3.3 for paths). Zed will recreate it on next launch. This loses workspace state but often resolves initialization crashes.

Diagnostic Information

From within Zed, access diagnostic info via:

• Command Palette > "zed: open log file" — application logs
• Command Palette > "zed: copy system specs" — system information for bug reports
• Command Palette > "zed: open local settings" — current settings with resolved values

The system_specs crate (crates/system_specs) gathers comprehensive system information.

Tip

When filing a bug report, always include the output of "zed: copy system specs". This includes your Zed version, release channel, OS version, GPU info, and relevant settings.

Environment Variables

Additional ZED_* environment variables are defined in crates/zed_env_vars/src.

Log Levels

Zed's logging system (crates/zlog, crates/zlog_settings) supports configurable log levels. Increase verbosity for debugging:

{
  "log_level": "debug"  // "error", "warn", "info", "debug", "trace"
}

Database Recovery

If the SQLite database becomes corrupted:

1. Close Zed completely
2. Navigate to the data directory (Section 3.3)
3. Rename or delete the database file
4. Restart Zed (it will create a fresh database)

You will lose workspace state (open files, window positions) but not your settings or keymaps (those are separate JSON files).