Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix LSP servers fail on Windows with ENOENT: uv_spawn cannot resolve .cmd shims [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#75352•Fetched 2026-05-01 05:34:49
View on GitHub
Comments
1
Participants
2
Timeline
2
Reactions
2
Author
ElliotDrelElliotDrel
Participants
clawsweeper[bot]clawsweeper[bot]ElliotDrelElliotDrel
Timeline (top)
commented ×1cross-referenced ×1

Root Cause

spawnLspServerProcess() in src/agents/pi-bundle-lsp-runtime.ts calls child_process.spawn(config.command, ...) directly. On Windows, npm installs CLI tools as .cmd wrapper scripts. Node.js spawn() without shell: true uses CreateProcess under the hood, which cannot find or execute .cmd files — even when they are present in PATH.

Fix Action

Fix

resolveWindowsSpawnProgram() already exists in src/plugin-sdk/windows-spawn.ts and handles this exactly — it finds the .cmd shim via PATH+PATHEXT, parses it to extract the real Node.js entrypoint, and returns a direct spawn invocation that requires no shell. It is already used for Docker and memory-host spawning but was not wired into the LSP spawn path.

See PR #75343 which applies this fix.

PR fix notes

PR #75343: fix(lsp): resolve Windows .cmd shims in spawnLspServerProcess

Description (problem / solution / changelog)

Fixes #75352

Problem

On Windows, LSP plugin servers (e.g. typescript-lsp) fail on startup with:

ENOENT: no such file or directory, uv_spawn 'typescript-language-server'

child_process.spawn() without shell: true cannot find or execute .cmd wrapper scripts that npm installs globally on Windows. Even when typescript-language-server.cmd is present in PATH, uv_spawn calls CreateProcess directly and cannot locate or execute .cmd files without shell mediation.

Root Cause

spawnLspServerProcess() in pi-bundle-lsp-runtime.ts calls spawn(config.command, ...) directly with no Windows PATH/PATHEXT resolution. This works on macOS/Linux where the npm shim is a proper executable, but fails on Windows where npm installs .cmd wrappers.

Fix

resolveWindowsSpawnProgram() already exists in src/plugin-sdk/windows-spawn.ts and handles this exactly:

  1. Finds typescript-language-server.cmd via PATH + PATHEXT search
  2. Parses the .cmd shim to extract the real Node.js entrypoint (cli.mjs)
  3. Returns { command: node.exe, leadingArgv: [cli.mjs] } — a direct spawn that needs no shell

The utility is already used for Docker and memory-host process spawning. This PR wires it up for LSP servers, which were the only remaining spawn site missing it.

Testing

Verified manually on Windows 11 with typescript-language-server installed via npm install -g typescript-language-server typescript.

Before: ENOENT: no such file or directory, uv_spawn 'typescript-language-server'
After: LSP server initializes and responds correctly

Notes

  • On non-Windows platforms, resolveWindowsSpawnProgram() is a no-op (returns { command, leadingArgv: [] }) so there is no behavioral change on macOS/Linux.
  • allowShellFallback: true ensures that even edge-case .cmd shims that can't be fully resolved still work via shell, rather than hard-failing.

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/agents/pi-bundle-lsp-runtime.ts (modified, +15/-3)

Code Example

ENOENT: no such file or directory, uv_spawn 'typescript-language-server'
RAW_BUFFERClick to expand / collapse

Problem

On Windows, any LSP plugin server fails on startup with:

ENOENT: no such file or directory, uv_spawn 'typescript-language-server'

This affects all LSP plugins (typescript-lsp, pyright-lsp, etc.) on Windows.

Root Cause

spawnLspServerProcess() in src/agents/pi-bundle-lsp-runtime.ts calls child_process.spawn(config.command, ...) directly. On Windows, npm installs CLI tools as .cmd wrapper scripts. Node.js spawn() without shell: true uses CreateProcess under the hood, which cannot find or execute .cmd files — even when they are present in PATH.

Why It Works on Mac/Linux

On macOS/Linux, npm installs a proper executable shim (a shell script with a shebang). Node.js spawn() can execute these directly. On Windows, only a .cmd file is installed, which requires shell mediation.

Fix

resolveWindowsSpawnProgram() already exists in src/plugin-sdk/windows-spawn.ts and handles this exactly — it finds the .cmd shim via PATH+PATHEXT, parses it to extract the real Node.js entrypoint, and returns a direct spawn invocation that requires no shell. It is already used for Docker and memory-host spawning but was not wired into the LSP spawn path.

See PR #75343 which applies this fix.

Environment

  • OS: Windows 11
  • Node.js: v22.14.0
  • Affected plugin: typescript-lsp (and likely all LSP plugins)

extent analysis

TL;DR

Use the existing resolveWindowsSpawnProgram() function to handle the spawn of LSP plugin servers on Windows.

Guidance

  • Review the spawnLspServerProcess() function in src/agents/pi-bundle-lsp-runtime.ts to ensure it uses resolveWindowsSpawnProgram() for Windows environments.
  • Verify that resolveWindowsSpawnProgram() is correctly implemented to find the .cmd shim via PATH and PATHEXT, and to extract the real Node.js entrypoint.
  • Apply the fix from PR #75343 to wire resolveWindowsSpawnProgram() into the LSP spawn path.
  • Test the fix with multiple LSP plugins (e.g., typescript-lsp, pyright-lsp) to ensure the issue is resolved.

Example

No code snippet is provided as the fix is already implemented in resolveWindowsSpawnProgram() and the necessary changes are described in PR #75343.

Notes

This fix assumes that resolveWindowsSpawnProgram() is correctly implemented and that the issue is solely due to the use of child_process.spawn() without shell mediation on Windows.

Recommendation

Apply the workaround by using resolveWindowsSpawnProgram() to handle the spawn of LSP plugin servers on Windows, as described in PR #75343, to resolve the ENOENT error.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#docker error#permission error#memory optimization#batch processing#GPU compatibility

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix LSP servers fail on Windows with ENOENT: uv_spawn cannot resolve .cmd shims [1 pull requests, 1 comments, 2 participants]