LSP tool refuses to run a working, PATH-resolved clangd on Windows ("unsafe location (current directory)")

The LSP tool's findReferences/goToDefinition/etc. fail unconditionally on Windows with:

Command 'clangd' not found or is in an unsafe location (current directory)

This happens even when clangd is:

• confirmed present and functional (clangd --version runs fine via the Bash tool)
• on PATH (verified with where clangd)
• installed via multiple methods: Scoop, winget install LLVM.LLVM (system-wide, Program Files), and a manual copy placed outside the project directory entirely

Moving the binary between locations (user-writable Scoop dir -> Program Files -> a folder outside the project root) produces the identical error every time, suggesting the check isn't really about filesystem location — it may be a hardcoded rejection tied to how the LSP tool resolves/spawns the process on Windows, not an actual "unsafe path" condition.

Notably, there's no dangerouslyDisableSandbox-style escape hatch for the LSP tool, unlike Bash/PowerShell. That asymmetry is the confusing part: the agent has full Bash exec access on the machine (can run arbitrary shell commands, install software, etc.) but is blocked from running a verified-safe, already-installed clangd purely for read-only code intelligence (find references, go to definition). Given Bash access is strictly more powerful than what LSP needs, this restriction doesn't seem to be adding real safety — just removing a useful feature.

Environment: Windows 11, clangd 22.1.8 (LLVM), clangd-lsp@claude-plugins-official plugin enabled.

Ask: Either fix the location-detection logic, or expose an override (env var / settings.json key / CLI flag) similar to dangerouslyDisableSandbox.

🤖 Filed via Claude Code