[BUG] LSP tool cannot resolve any language server on Windows (v2.1.208) - 'not found or is in an unsafe location' even for real .exe servers on static PATH

Environment

• Claude Code: v2.1.208 (native install, %USERPROFILE%\.local\bin\claude.exe)
• OS: Windows 11 Pro 26H2, build 26300.8772 (Insider), win32 x64
• Plugins (all claude-plugins-official, v1.0.0, commit 26db21a): typescript-lsp, pyright-lsp, rust-analyzer-lsp
• Language servers installed:
• typescript-language-server 5.3.0 + typescript 7.0.2 via npm i -g (npm ships .cmd/.ps1 shims, no .exe)
• pyright-langserver.exe (pip-generated real PE executable) in a conda env Scripts\ dir that is a static per-user registry PATH entry
• rust-analyzer.exe (rustup component proxy, real PE executable) in F:\rust\cargo\bin, also a static per-user registry PATH entry

What happened

Every LSP tool invocation fails identically for all three servers, e.g.:

Error performing documentSymbol: Command 'typescript-language-server' not found or is in an unsafe location (current directory)
Error performing documentSymbol: Command 'pyright-langserver' not found or is in an unsafe location (current directory)
Error performing documentSymbol: Command 'rust-analyzer' not found or is in an unsafe location (current directory)

(documentSymbol on .ts, .py, .rs files respectively.)

Evidence the binaries are present and on the process-tree PATH

Run from a shell child of the same Claude Code session (i.e. inheriting the same environment the LSP resolver sees):

(Get-Command rust-analyzer).Source            # -> F:\rust\cargo\bin\rust-analyzer.exe
Test-Path F:\anaconda3\envs\<env>\Scripts\pyright-langserver.exe   # -> True
typescript-language-server --version          # -> 5.3.0

The two .exe servers live in static user-registry PATH directories (not added by any shell profile), so the Claude Code process and all of its children share them. Child shells resolve all three commands; only the LSP tool's own resolver fails.

Steps to reproduce

1. On Windows, install any official LSP plugin (e.g. rust-analyzer-lsp) and its server so that a real server.exe is on a static PATH directory (e.g. rustup component add rust-analyzer with CARGO_HOME bin on PATH).
2. Ask Claude to use the LSP tool (e.g. documentSymbol) on a matching source file.
3. Observe Command 'rust-analyzer' not found or is in an unsafe location (current directory) despite where rust-analyzer succeeding in any shell.

Root-cause hypothesis

The server-binary lookup on win32 appears to check each PATH directory for the literal command name without appending .exe / honoring PATHEXT. That would fail every server uniformly — which is exactly what is observed: extension-less npm shims (typescript-language-server) and real executables (rust-analyzer.exe, pyright-langserver.exe) all report "not found". A .cmd-spawn restriction (Node's post-CVE-2024-27980 behavior) could additionally affect npm-shim servers, but it cannot explain the .exe failures, so the primary defect looks like extension-naive PATH resolution.

Workaround attempted (failed)

Placing a typescript-language-server.cmd wrapper in another static PATH directory is also not picked up — consistent with the lookup never matching anything that isn't the bare literal filename.

Session context

Observed in a daemon-spawned background (headless job) session; I can't rule out interactive sessions behaving differently, but since the failing directories are static registry PATH entries inherited by the whole process tree — and child shells of the same session resolve all three binaries — the resolver itself appears platform-broken.

Impact

All three official LSP plugins (typescript-lsp, pyright-lsp, rust-analyzer-lsp 1.0.0) are non-functional on Windows native — the LSP tool cannot start any language server.