[LSP] Language servers on user PATH not found — "Command 'X' not found or is in an unsafe location (current directory)" (rust-analyzer + clangd, Windows)

Summary

The Claude Code LSP plugin host fails to launch any language server whose binary lives on the user PATH (rather than the machine/system PATH), erroring with:

Command 'rust-analyzer' not found or is in an unsafe location (current directory)

The identical failure happens with clangd. Both binaries are correctly installed, on the user's PATH, and run fine from a shell. LSP is therefore completely unusable for Rust and C/C++ on this setup.

Because rust-analyzer-lsp and clangd fail the same way, this is the shared LSP host / server-resolution logic, not a per-plugin bug.

Environment

• OS: Windows 11
• Claude Code: desktop app
• Plugins (claude-plugins-official): rust-analyzer-lsp v1.0.0, clangd
• rust-analyzer 1.96.1 — %USERPROFILE%\.cargo\bin\rust-analyzer.exe (rustup proxy). rust-analyzer --version works in a shell.
• clangd — %LOCALAPPDATA%\Programs\clangd\22.1.6\bin\clangd.exe, on the user PATH. clangd --version works in a shell.

Reproduction

1. rustup component add rust-analyzer (proxy lands in ~/.cargo/bin, which is on the user PATH).
2. Open a Rust project; invoke any LSP operation (e.g. workspaceSymbol).
3. → Command 'rust-analyzer' not found or is in an unsafe location (current directory).
4. Same on a C/C++ file → Command 'clangd' not found or is in an unsafe location (current directory).

What was ruled out (extensively)

• Binary is fine: rust-analyzer --version / clangd --version both run from a shell on the same machine/user.
• Not the rustup symlink shim: replacing ~/.cargo/bin/rust-analyzer.exe (symlink → rustup.exe) with a real copy of the binary / a copy of rustup.exe — no change.
• Not editor-specific: identical failure in both VS Code and Zed.
• Not the PATH location: placing a working proxy in %LOCALAPPDATA%\Microsoft\WindowsApps (user PATH) and in C:\Windows\System32 (system PATH — on every process's PATH), followed by a full app restart, still fails identically.
• Affects both plugins the same way → shared host, not per-plugin.

Likely cause

The LSP host process appears to run with a stripped environment that omits the user's PATH entries, and/or resolves the server binary once at host startup and caches the "not found" result (adding the binary to System32 afterward + restarting did not help). The "unsafe location (current directory)" guard may additionally be over-rejecting otherwise-valid resolutions.

Impact

Go-to-definition, find-references, diagnostics, and symbol search are entirely unavailable for Rust and C/C++, despite correctly-installed, PATH-available, working language servers. This is a poor first-run experience: users install exactly what the plugin READMEs instruct (rustup component add rust-analyzer, clangd on PATH), the binaries work everywhere else on the machine, yet the plugin never finds them — with no configuration knob to point it at the right path.

Suggested fixes

1. Spawn the LSP host with the full user environment/PATH (not just the system PATH).
2. Additionally probe common per-user install locations (~/.cargo/bin, %LOCALAPPDATA%\Programs\..., Homebrew, etc.).
3. Provide an explicit command / server-binary-path override in plugin or user config.
4. Re-resolve the server per request instead of caching a startup "not found".