[BUG] LSP plugin (csharp-ls) spawn fails with "unsafe location (current directory)" despite valid PATH resolution, then permanently disconnects the LSP MCP server

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Environment: Windows 11, Claude Code CLI, csharp-lsp@claude-plugins-official plugin enabled, csharp-ls installed via dotnet tool install --global csharp-ls at %USERPROFILE%\.dotnet\tools\csharp-ls.exe.

Steps to reproduce:

1. Install csharp-ls via the .NET global tool (lands in ~/.dotnet/tools, confirmed on both user and process PATH).
2. Enable the csharp-lsp plugin in Claude Code.
3. Call any LSP operation (e.g. documentSymbol) on a .cs file.

Expected: csharp-ls launches and services the request.

Actual: The call fails with:
Command 'csharp-ls' not found or is in an unsafe location (current directory)
despite csharp-ls.exe being present at a PATH-resolved absolute location with no ./empty entries in PATH. Immediately after this failure, the LSP MCP server disconnects entirely for the rest of the session — no further LSP tool calls are available, even after the underlying binary is confirmed reachable from a normal shell.

Diagnosis already done:

• Verified csharp-ls.exe exists and both where/which resolve it correctly.
• Verified .dotnet\tools is on PATH (user and process scope).
• Verified no ./empty PATH entries (ruling out the classic relative-path hijack case).
• Verified no settings.json/settings.local.json/policy-limits.json restrictions reference this executable or path.

Likely root cause: Same defect as #43840 and #67821 — the executable-path safety check appears to compare the resolved path against the current working directory (something like resolvedPath.startsWith(cwd)) and misfires on valid PATH-resolved binaries. This report adds two new facts not covered by those issues: (1) the same defect reaches the LSP plugin subprocess spawn path, not just git/cmd/tmux, and (2) a failed spawn here doesn't just fail one call — it kills the entire LSP MCP server for the rest of the session.

References: #67821, #43840, #29307

What Should Happen?

csharp-ls launches and services the request.

Error Messages/Logs

Command 'csharp-ls' not found or is in an unsafe location (current directory)

Steps to Reproduce

1. Install csharp-ls via the .NET global tool (lands in ~/.dotnet/tools, confirmed on both user and process PATH).
2. Enable the csharp-lsp plugin in Claude Code.
3. Call any LSP operation (e.g. documentSymbol) on a .cs file.

Claude Model

Sonnet (default)

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.202

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_