Debugging language server issues in Zed: when 'no completions' is your problem

Published 2026-03-30 by Owner

Zed’s language server experience is good when it works. When it breaks, the symptoms — missing completions, no go-to-definition, broken diagnostics — point to “the editor is broken” rather than “the LSP is broken.” Several debugging tricks have saved me hours over the past year.

Symptom: completions stopped working in one project

You open a Rust project. Completions don’t appear. Go-to-definition does nothing. The editor feels fine on other projects.

First check: is the language server actually running?

ps aux | grep rust-analyzer

If you don’t see it, Zed didn’t start the server. Common reasons:

1. rust-analyzer not in PATH
2. Project doesn’t match Zed’s detection (no Cargo.toml at the expected level)
3. The server crashed at startup

If you see it but completions still don’t work, the server is running but Zed isn’t talking to it correctly.

The Zed log

Open Zed’s log file:

tail -f ~/Library/Logs/Zed/Zed.log    # Mac
tail -f ~/.local/share/zed/logs/Zed.log    # Linux

Open your project file in Zed. Watch the log. You’ll see entries like:

2026-03-15T14:32:11Z INFO  zed::lsp: Starting language server "rust-analyzer" for "rust"
2026-03-15T14:32:11Z INFO  zed::lsp: stdout: { "jsonrpc": "2.0", "method": "initialize", ... }

If you see startup logs but no further activity, the server is running but not communicating. Common cause: workspace folder mismatch. The server is looking for a project root in a place Zed isn’t sending requests for.

If you see nothing, the server didn’t start. Check the binary path:

Settings → Languages & Frameworks → Rust → Language server path

For most languages, the default works. For language servers installed via project-specific tooling (e.g., pyright from a virtualenv), you may need to specify the path explicitly.

Symptom: “loading workspace” never finishes

Some language servers (rust-analyzer, gopls, basedpyright) take time to index large projects. For very large projects, this can be 5-15 minutes on first open. Subsequent opens use cached indexes and are faster.

If “loading workspace” takes more than 20 minutes, something’s wrong. Things to check:

rust-analyzer: It’s trying to compile your project to build the index. If your project doesn’t compile cleanly (cargo check fails), rust-analyzer can stall indefinitely. Fix compilation errors first.

gopls: It’s loading dependencies. If you have a network issue or go.sum is corrupt, gopls can hang. Try go mod download from the terminal first.

basedpyright/pyright: It’s typechecking everything. If you have a circular import or generated stubs issue, it can spin. Add an exclude rule in pyrightconfig.json for problematic directories.

For all of these, the language server’s own logs are the source of truth. Find them in:

~/.cache/rust-analyzer/    # rust-analyzer
$GOPATH/pkg/mod/cache/    # gopls cache

The Zed log shows what Zed sent to the server; the server’s logs show what the server tried to do.

Symptom: completions are slow

If completions appear but take 1-3 seconds each, the server is responding but slowly. Common causes:

Index is rebuilding in background. Wait. After 1-2 minutes, completions should be fast.

Server is on the wrong branch. rust-analyzer specifically: if you have multiple cargo workspaces and rust-analyzer is indexing the wrong one, requests for the right one fall back to slow paths.

Insufficient memory. Large projects need RAM. rust-analyzer at peak can use 4-6GB. If your machine swaps, completion performance tanks. Close other apps.

Wrong language server settings. Some servers have settings that control performance. For rust-analyzer:

{
  "rust-analyzer.cargo.allFeatures": false,
  "rust-analyzer.checkOnSave.enable": false
}

allFeatures: false and checkOnSave: false reduce the work the server does. For development, this is usually fine. Re-enable when you need the deeper analysis.

Symptom: diagnostics are wrong

You see errors that aren’t real, or you don’t see errors that are real. The language server’s view of your project doesn’t match reality.

This is almost always a stale state issue. Solutions in order of severity:

1. Save the file (forces re-analysis)
2. Reopen the project in Zed
3. Restart the language server (Command Palette → “Restart Language Server”)
4. Delete the language server’s cache:
   • rust-analyzer: rm -rf ~/.cache/rust-analyzer
   • gopls: go clean -modcache (drastic)
   • pyright: delete node_modules/.cache/pyright
5. Check that your tool versions match what’s expected (rustc --version, etc.)

In my experience, step 3 fixes the issue 80% of the time. The cache deletion is for the persistent cases.

Symptom: “Language Server Not Configured”

Zed shows a notification that the language server isn’t configured. This means Zed knows the file’s language but doesn’t have a default server installed.

For most languages, Zed auto-installs the server on first open. If auto-install fails (network issue, permissions), you’ll see this notification.

To install manually:

# Rust
rustup component add rust-analyzer

# Go
go install golang.org/x/tools/gopls@latest

# TypeScript (vtsls or typescript-language-server)
npm install -g vscode-langservers-extracted

Then restart Zed. The server should be picked up automatically.

For uncommon languages, Zed has extensions in its marketplace. Search for the language; install the extension; the language server is bundled in or auto-installed when the extension activates.

Symptom: works in editor, fails in CLI

Sometimes Zed shows no errors but cargo build (or equivalent) fails. The reverse: cargo build succeeds but Zed shows errors.

This means Zed’s language server is using a different toolchain or set of feature flags than your CLI build.

Check your rust-toolchain.toml (or equivalent). If your project has one, make sure Zed picks it up. For rust-analyzer specifically, the workspace settings:

{
  "rust-analyzer.checkOnSave.command": "clippy",
  "rust-analyzer.cargo.features": "all",
  "rust-analyzer.rustc.source": "discover"
}

features: "all" enables all crate features for analysis. If your CLI build uses specific features, mismatch is possible.

When to give up and restart

If you’ve tried the above and the language server is still misbehaving, restart everything:

1. Quit Zed
2. Kill any orphaned language server processes
3. Restart the machine if you’re really unsure
4. Reopen Zed
5. Open the project

This works 99% of the time. The 1% of cases that don’t resolve usually point to a real bug — file an issue with the Zed team. They’re responsive and good language server bugs get fixed.

What I wish Zed had

A “language server diagnostic dashboard” — one place to see all running servers, their status, their resource usage, and recent log output — would save time across all the issues above.

Currently you cobble it together from ps, the Zed log, and the language server’s own log. That works but is more friction than necessary. Zed’s UX is generally clean; this corner is rougher than the rest.