LSP tool not registered on Windows even with native LSP-server binary

Resolved 💬 3 comments Opened Apr 29, 2026 by rsmith-primed Closed May 3, 2026

Environment

  • Claude Desktop on Windows, bundled Claude Code 2.1.121 (%APPDATA%\Claude\claude-code\2.1.121\claude.exe)
  • Also reproduces with standalone Claude Code 2.1.122 from npm (%APPDATA%\npm\claude.cmd)
  • ~/.claude/settings.json has "env": {"ENABLE_LSP_TOOL": "1"} — verified ENABLE_LSP_TOOL=1 is present in the running process environment via env | grep
  • Project .lsp.json correctly configured by the dbt-lsp-bundle plugin:

``json
{
"dbt": {
"command": "dbt",
"args": ["lsp"],
"transport": "stdio",
"extensionToLanguage": {"sql": "dbt-sql", "yml": "dbt-yaml", "yaml": "dbt-yaml"},
"initializationOptions": {"projectRoot": "${workspaceRoot}"}
}
}
``

  • The LSP server binary is a native dbt.exe at C:\Users\<user>\.local\bin\dbt.exe (dbt-fusion 2.0.0-preview.173). where dbt resolves to the .exe directly — not an npm .cmd wrapper.

Expected

An LSP tool registered in the Claude Code session, callable as LSP.goToDefinition, LSP.hover, etc. (per the dbt-lsp-bundle skill documentation).

Actual

No LSP tool registered. Tool listing returns nothing for lsp, language server, goToDefinition, or select:LSP. The tool isn't failing on spawn — it's not present in the tool registry at all.

Verified independently by running claude --print "list every tool you have available that starts with LSP" in a separate terminal: response confirms no LSP-prefixed tools.

Distinct from existing Windows LSP issues

This is not the same as the .cmd-wrapper spawn bugs:

  • #33484 — LSP plugin Windows npm .cmd spawning
  • #17136 — TypeScript LSP Windows wrapper script
  • #15914 — LSP plugin loading

Those track failures spawning npm-installed servers (which are .cmd shims). In this report the underlying LSP server is a native .exe, so any spawn-of-shim path doesn't apply. The failure mode is also different — registration appears to fail silently before any spawn attempt, since no LSP tool is exposed at all.

Diagnostic info gathered

| Check | Result |
|---|---|
| ENABLE_LSP_TOOL=1 in process env | ✅ Yes |
| ~/.claude/settings.json env block honored | ✅ Yes |
| .lsp.json exists at project root | ✅ Yes |
| .lsp.json is valid JSON | ✅ Yes |
| dbt --version works from PATH | ✅ dbt-fusion 2.0.0-preview.173 |
| where dbt resolves to | C:\Users\<user>\.local\bin\dbt.exe (native, not .cmd) |
| LSP tool registered | ❌ Not present |

Repro steps

  1. Install dbt-fusion native binary (dbt.exe) on Windows PATH
  2. Create a .lsp.json at the workspace root pointing to dbt lsp
  3. Set env.ENABLE_LSP_TOOL=1 in ~/.claude/settings.json
  4. Launch Claude Desktop (or the npm CLI), open the workspace
  5. Ask Claude to list available tools — no LSP tool present

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗