Problem: node: not found inside WSL (npm came from the Windows side) —— Trove problem library

What you will run into

Running ccr or other npm global commands inside WSL reports node: not found, while the same command works on the Windows side.

The reason is the package was installed by the Windows build (the script shebang points at Windows node), or Windows paths take priority over WSL-native paths in PATH - the two sides have two separate Node stacks; don't mix them.

Why this happens

WSL and Windows each have their own node/npm global directories.

If you npm install -g on the Windows side, the generated command script's shebang points at Windows' node.exe; running it inside WSL can't find the matching interpreter and reports node: not found.

Conversely, when Windows paths come first in PATH, node inside WSL resolves to the Windows build and behaves oddly.

An npm global command is actually a shell script (not a binary): on npm install -g, npm generates an executable script in the global bin dir whose first line is a shebang pointing at an interpreter (e.g.

#!/usr/bin/env node, or an absolute path to node.exe).

The shebang is written at install time on that machine's interpreter: installed on the Windows side, it points at Windows' node.exe — when you run it inside WSL, there is no node.exe in the WSL environment (it's a Windows PE executable), hence node: not found.

Conversely, when Windows paths (/mnt/c/...) come first in WSL's PATH, node resolves to the Windows build of node.exe — WSL can execute it (via interop), but behavior, paths and performance all differ from the native build.

That's the mechanism behind "the two sides are two separate stacks; don't mix them".

The fix is fixed accordingly: install native Node inside WSL (nvm/apt), reinstall the global package into the WSL-side npm bin so the shebang points at the WSL interpreter; verify with which node to see the resolved path.

Step by step

1. Install native Node inside WSL — Required

nvm install 22 && nvm use 22

(Or install nodejs/npm via apt.) Make sure /usr/bin or the nvm path comes before Windows paths in PATH.

2. Verify the active version — Required

which node && node --version

which node pointing to a WSL-internal path (/usr/bin or ~/.nvm) is correct.

3. Reinstall into the WSL-side global — Required

npm install -g @musistudio/claude-code-router

Don't mix the two sides' npm global directories; if an old command script lingers, rm $(which ccr) to remove the Windows-side copy.

How to confirm it works

which ccr && ccr --version

The command runs inside WSL = success (measured: WSL-native Node + npm global chain works).

Other environments

Symptom

Running ccr or npm global commands inside WSL reports node: not found; the same command works on the Windows side.

Cause

The npm package was installed by the Windows build (the script shebang points at Windows node), or Windows paths take priority over WSL-native paths in PATH.

Solution

1. Install native Node inside WSL (nvm or apt); make sure /usr/bin comes first in PATH.
2. Reopen the shell and verify: which node, node --version.
3. Don't mix the two sides' npm global directories (reinstall into the WSL-side global).