Debugging

Logs

Zed uses the project-internal crates/zlog crate. It wraps a structured logger with log!, info!, warn!, error!, and ergonomic feature gating.

By default, logs go to:

• macOS: ~/Library/Logs/Zed/Zed.log
• Linux: ~/.local/share/zed/logs/Zed.log
• Windows: %LOCALAPPDATA%\Zed\logs\Zed.log

Run with --foreground to log to stderr instead:

cargo run -- --foreground

Configure log filtering through environment variables (RUST_LOG-style) or via the zlog_settings crate at runtime.

Inside Zed: the language-server log viewer

crates/language_tools exposes an in-app log viewer for language servers. Invoke dev: open language server logs from the command palette. There is also a request/response inspector that's invaluable when chasing LSP-side bugs.

Inside Zed: the input-latency overlay

crates/input_latency_ui shows per-frame input latency. Useful when tuning rendering performance.

Inside Zed: the inspector

crates/inspector_ui is a GPUI element-tree inspector. Helpful for "why is this view not rendering?" investigations.

Inside Zed: the tracing UI

crates/ztracing and crates/miniprofiler_ui provide a Chrome-tracing-compatible profiler. The tracy Cargo feature (on the zed crate) wires up Tracy support if you have the desktop tool.

Crash reports

Crashes are routed to Sentry via crates/crashes. The integration is documented in .rules:

• Investigation prompts: .factory/prompts/crash/investigate.md
• Fix prompts: .factory/prompts/crash/fix.md
• Fetch a crash: script/sentry-fetch <issue-id>
• Generate an investigation prompt from a crash: script/crash-to-prompt <issue-id>

The latter two scripts industrialize the "Sentry → AI session" loop: paste the resulting prompt into your editor's AI panel and it has all the context it needs.

Debugging the editor in the editor

Zed has a built-in DAP-based debugger. See Debugger. The relevant crates are dap, dap_adapters, debugger_tools, debugger_ui. Once the project is configured (via tasks.json and a debug adapter), launch from the debugger panel.

For Rust, lldb and codelldb are typical choices. The debugger_tools crate carries development-time helpers (DAP message inspector, etc.).

Common errors

• "This operation requires a &mut Window" — you are trying to update an entity inside a place that has only an &App. Add update_in or pass the window explicitly.
• "already borrowed" — you tried to update an entity that is already being updated higher up the call stack. Refactor to release the outer borrow before re-entering.
• run_until_parked() hangs — see Testing → Timers in tests. Almost always smol::Timer::after masquerading as a GPUI-tracked timer.
• LSP not starting — check language_tools log viewer; the adapter probably failed during install.
• Extension not loading — check extension_host logs and make sure extensions/ paths and the WASM ABI version match.

Telemetry-driven debugging

crates/telemetry and crates/telemetry_events capture structured events. Enable opt-in metrics in settings, then inspect locally before they ship:

• Check telemetry::ClickhouseEvent and the schemas in telemetry_events.
• For privacy, raw payloads are batched and scrubbed before send.

Reaching Sentry directly

If you have permission, script/sentry-fetch <issue-id> is the lowest-friction path. For browse-the-issue debugging, the Sentry web UI is canonical.