DSH plugin exits 127 under MSYS2: use a native shell

If you run npx @deepseek-ai/dsh web or bunx @deepseek-ai/dsh web in an MSYS2 terminal (CLANG64 environment) and the command exits instantly with no console output and echo $? returns 127, this is not a missing package. Exit code 127 means "command not found", and it can be returned by the MSYS command/shim layer before the DeepSeek Harness profile is mounted. The key clue is that npx (Node) and bunx (Bun) both fail, which rules out the package runner and points at MSYS2's hybrid environment itself (#1624).

DSH plugin symptom: the command exits silently with code 127

What characterises this failure is not an error message but silence — no log, no exception, only a number produced by the outer layer. Concretely:

1. The repro is minimal: install Node under MSYS2 CLANG64 with pacman -S $MINGW_PACKAGE_PREFIX-nodejs, then run:

$ npx @deepseek-ai/dsh web

$ echo $?
127

The expectation is the Web UI starting on http://127.0.0.1:3080; the reality is an immediate silent exit (#1624). 2. bunx fails the same way: this matters — if only npx were broken you would suspect the package runner, but both paths failing narrows the suspicion to the dsh command's own startup in this environment (#1624). 3. The failure happens very early: "the command exits silently with no error message" typically points at "the failure occurs in the earliest stage of startup" — still at the command-resolution layer, not after plugins have come up (#1624). 4. Do not confuse it with the other Windows failure: #197 (koffi native module crashes on some Windows 10 machines) exits with 3221225477 and carries error messages, which is a different failure mode entirely. Ruling it out keeps you from investigating in the wrong direction (#1624). 5. A completely different failure showed up later too: on native Command Prompt with native Node, the reporter later hit V8 heap exhaustion at 0.1.1-rc.2 (Ineffective mark-compacts near heap limit / JavaScript heap out of memory), unrelated to MSYS2's 127. Do not misread that log as this problem (#1624).

DSH plugin mechanism: the path-resolution boundary of an MSYS2 hybrid environment

The core conflict is that "the process is correctly identified as Windows" and "command discovery is Unix-style" hold at the same time. Layer by layer:

1. The shipped composition selects its tool stack from process.platform: on win32 it disables tool-bash and enables tool-pwsh. That is, whenever process.platform is win32, the host configures tools as if PowerShell is available (#1624).
2. The node MSYS2 provides really is a Windows process: measured under CLANG64 by the reporter:

$ which -a node npm npx
/clang64/bin/node
/clang64/bin/npm
/clang64/bin/npx

$ node -p "JSON.stringify({ platform: process.platform, arch: process.arch, execPath: process.execPath })"
{"platform":"win32","arch":"x64","execPath":"C:\\Users\\fufu\\Downloads\\msys64\\clang64\\bin\\node.exe"}

$ npx --yes @deepseek-ai/dsh@latest --version; echo $?
0.1.0-rc.6
0

Note two things: platform is win32, yet node resolves to an MSYS2 path /clang64/bin/...; and --version returns normally with exit code 0. So the failure is neither "Node cannot start" nor "the package cannot be found" — it is a later step (#1624). 3. The reporter's diagnosis: a path-resolution problem before the pwsh tool loads. Their reading is that dsh or one of its dependencies detects Windows and therefore assumes Windows-style paths (C:\foo\bar), while MSYS2 supplies MSYS2-style paths (/c/foo/bar), so binary lookup fails. That also explains why the failure precedes the point where the tool stack is actually usable (#1624). 4. Install-time scripts are a secondary suspect: with bun add @deepseek-ai/dsh, Bun reported 4 blocked postinstalls, of which @deepseek-ai/dsh-subprocess-local's [postinstall] node scripts/ensure-spawn-helper.mjs is especially interesting — the "ensure spawn helper" logic may not take effect as intended on MSYS2, and koffi's install script is among the blocked ones too. This suggests that install-time native helper generation and runtime path resolution may both contribute (#1624). 5. A decisive control experiment: the reporter uninstalled MSYS2's own nodejs, started a new shell with msys2_shell.cmd -clang64 -use-full-path to inherit the system PATH, and then npx / bunx installed by the system npm worked. That contrast is valuable — it shows the problem lies in the MINGW nodejs/python toolchain patches, which make the toolchain "believe it is in a Unix shell while it is actually on Windows", an assumption that does not hold for DeepSeek Harness (#1624). 6. A viable product-side improvement direction: the reporter suggested the host recognise MSYS2 via an environment variable such as MSYSTEM_PREFIX and use MSYS2-style paths instead of Windows-style variable resolution; further, invoke a Unix-like shell directly on MSYS2 to bring full Unix shell power to Windows. These improve hybrid-environment compatibility rather than asking users to change their environment (#1624).

DSH plugin triage and workaround: four commands, native shell, version alignment

First use four commands to split "which layer failed", then decide whether to change the environment or wait for a version. Specifically:

1. Step one: determine whether the package's own bin can execute at all. In MSYS2, run these four and record each output:

which -a node npm npx
node -p "JSON.stringify({ platform: process.platform, arch: process.arch, execPath: process.execPath })"
npx --yes @deepseek-ai/dsh@latest --version
echo $?

How to read it: if --version also returns 127, the failure is in the npm/MSYS bin resolution before the Web or Cordis graph starts (because DeepSeek Harness's bin handles --version before dynamically importing the profile boot path); if --version works while web returns 127, continue with npx --yes @deepseek-ai/dsh@latest --profile web --dump-config, capturing both stdout and stderr (#1624). 2. Step two: use a native shell as the control experiment (and as today's most practical workaround). In native Windows PowerShell or Command Prompt, using a native Windows Node installation (not MSYS2's pacman Node build):

where.exe node
node -p "JSON.stringify({ platform: process.platform, arch: process.arch, execPath: process.execPath })"
npx --yes @deepseek-ai/dsh@latest --version
npx --yes @deepseek-ai/dsh@latest web

If the native shell succeeds, this is essentially isolated as an MSYS2 launcher compatibility issue rather than the Windows native-module crash of #197; if it still fails, paste those four diagnostic outputs plus npm --version, which shows whether both shells resolve the same node.exe and npm shim (#1624). 3. Step three: another verified MSYS2-internal variant. Uninstall MSYS2's nodejs, start the shell with msys2_shell.cmd -clang64 -use-full-path to inherit the system PATH, and run npx / bunx from the system npm. This path is verified working, at the cost of no longer using the MINGW Node build (#1624). 4. Step four: align versions. The reporter confirmed on 2026-09-09 that Windows support recovered on 0.1.2-rc.1, so upgrading to that or newer and retesting is reasonable. But remember the caveat: bunx under MSYS2 still fails silently — so even after the upgrade, the bunx path inside MSYS2 cannot be treated as verified (#1624). 5. Step five: do not merge distinct failures into one conclusion. The same thread produced three different phenomena over time: MSYS2's silent 127, V8 heap exhaustion on a native shell, and a Bun failure log on Linux. They come from different times and environments, so none of them supports a conclusion that "Windows is broken across the board", and one should not be used to explain another (#1624). 6. What this means for plugin authors: anywhere a cross-platform plugin depends on an external executable or path joining, be explicit about whether you received a Windows path or an MSYS2 path. When you distribute such a plugin through DSH Plugin Hub, a silent exit under MSYS2 or Git Bash looks exactly like this 127 to the user — so either detect these environments and emit a readable error, or state plainly in your docs that a native shell is recommended (#1624).

DSH plugin troubleshooting notes

Remember first that 127 is not a missing package — it may be a number returned by the MSYS shim layer before the profile mounts, so splitting "which layer failed" beats reinstalling. Eight points to keep in mind when a DeepSeek Harness plugin exits with 127 on Windows:

1. 127 ≠ missing package: it may be returned by the MSYS shim layer before the profile mounts.
2. Test --version first: it separates "bin resolution failed" from "failed after profile boot".
3. Both npx and bunx failing: the problem is the environment/command, not the package runner.
4. A native shell is the first choice: the composition enables tool-pwsh and disables tool-bash on win32, and hybrid environments tend to trip there.
5. The MSYS2-internal variant works but swaps toolchains: inherited system PATH plus system-npm npx/bunx.
6. Do not confuse it with #197: that one is a koffi native crash (exit code 3221225477, with an error message).
7. Windows support recovered from 0.1.2-rc.1, but bunx under MSYS2 is still unconfirmed.
8. Decide the path style explicitly: when writing cross-platform plugins, do not assume "Windows means Windows-style paths".

Sources: Discussion #1624, Windows compatibility guide, Discussion #197.