Bug: npx @deepseek-ai/dsh web fails silently on MSYS2 (exit code 127)

[fufurobot]

Description

When running npx @deepseek-ai/dsh web (or bunx @deepseek-ai/dsh web) inside an MSYS2 terminal (CLANG64 environment), the command exits immediately with no output and returns exit code 127. The web UI does not start.

Steps to Reproduce

1. Set up an MSYS2 environment (CLANG64).
2. Install Node.js via pacman -S $MINGW_PACKAGE_PREFIX-nodejs.
3. (Optional) Install Bun via npm install -g bun.
4. Run the command:

   npx @deepseek-ai/dsh web

   or

   bunx @deepseek-ai/dsh web

Expected Behavior

The command should start the DSH Web UI, which is served at http://127.0.0.1:3080 by default.

Actual Behavior

The command exits immediately with no console output. Checking the exit code shows 127:

$ npx @deepseek-ai/dsh web

$ echo $?
127

Environment

• OS: Windows 11 (with MSYS2)
• Terminal: MSYS2 CLANG64
• Node.js: Installed via pacman -S $MINGW_PACKAGE_PREFIX-nodejs
• Bun: Installed via npm install -g bun (optional)
• DSH Version: Latest (fetched via npx/bunx)

Additional Context

Exit code 127 typically indicates "command not found". In MSYS2 environments, this can occur when Node.js's child_process.spawn() attempts to execute a binary that is not in the Windows PATH or when there are path format mismatches between Unix-style (MSYS2) and Windows-style paths.

This issue might be related to how dsh spawns subprocesses or locates native binaries. The problem occurs with both npx (Node.js) and bunx (Bun), suggesting it is not specific to the package runner but rather to the dsh command itself when run in this environment.

Possible Cause

The dsh command or one of its dependencies may be attempting to execute a binary that is not available in the MSYS2 environment, or there may be a path resolution issue. Given that the command exits silently without any error message, the failure likely occurs very early in the startup process.

Related Issues

• Discussion dsh 在部分 Windows 10 机器上因 koffi 原生崩溃而不可用（含症状/修复思路/修改过程） #197 ("dsh 在部分 Windows 10 机器上因 koffi 原生崩溃而不可用") describes native module crashes on Windows, but that issue manifests with different symptoms (crashes with exit code 3221225477 and error messages). The MSYS2 issue appears to be a different failure mode.

[denial123789]

This looks like a launch-boundary failure, but the current evidence is not enough to attribute it to a specific DSH child process yet. Exit 127 can be returned by the MSYS command/shim layer before the DSH profile is mounted.

A useful first split is whether the package bin can execute at all:

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 $?

The DSH bin handles --version before dynamically importing the profile boot path (source at the reported revision). Therefore:

• if --version also returns 127, the failure is in npm/MSYS bin resolution before Web or the Cordis graph starts;
• if --version works but web returns 127, continue with npx --yes @deepseek-ai/dsh@latest --profile web --dump-config and capture both stdout and stderr.

For a current workaround and a cleaner control experiment, launch from native Windows PowerShell or Command Prompt using a native Windows Node installation, not the MSYS2 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

This distinction matters because the shipped composition selects its Windows tool stack from process.platform: it disables tool-bash and enables tool-pwsh on win32 (composition source). MSYS2 is a hybrid environment: Unix-style command discovery and paths can wrap a process that DSH correctly sees as Windows and configures for PowerShell.

If the native-shell run succeeds, that isolates this as an MSYS2 launcher compatibility issue rather than the Windows native-module crash discussed in #197. If it still fails, please paste the four diagnostic outputs above plus npm --version; that will show whether both shells resolve the same node.exe and npm shim.

I have also collected the current native-Windows versus hybrid-shell boundaries in this Windows compatibility guide. The guide is supplementary; the source links above are the authoritative behavior.

[fufurobot]

If the native-shell run succeeds, that isolates this as an MSYS2 launcher compatibility issue rather than the Windows native-module crash discussed in #197. If it still fails, please paste the four diagnostic outputs above plus npm --version; that will show whether both shells resolve the same node.exe and npm shim.

both shells should not resolve the same node.exe and npm shim. The msys2 is not designed to reuse the nodejs tool chain that implies MSVC on windows; It has been heavily patched to use GNU toolchain.

I have also collected the current native-Windows versus hybrid-shell boundaries in this Windows compatibility guide. The guide is supplementary; the source links above are the authoritative behavior.

Nevertheless, the powershell command is resolvable on MSYS2 since it inherits windows PATH; I believe it should work seamlessly on MSYS2.

[fufurobot]

To clarify, the powershell support is not because it inherits PATH in windows; it is because msys2 have hard-coded them inside MSYS2.

fufu@gpdwin4 MINGW64 ~
$ printenv PATH
/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl

fufu@gpdwin4 MINGW64 ~
$ which powershell
/c/Windows/System32/WindowsPowerShell/v1.0/powershell

[denial123789]

Thanks — that distinction is correct, and my earlier “same node.exe and npm shim” wording was wrong as an expectation.

The MSYS2/MINGW Node package is a separately patched GNU-toolchain build, so different Node/npm resolution is normal. Comparing the paths is still useful diagnostic evidence, but only to identify which runtime owns the failing launch; it should not be presented as a requirement that MSYS2 reuse the MSVC Windows toolchain.

Your PATH example also gives the more precise explanation for PowerShell discovery: MSYS2's configured default PATH includes the Windows PowerShell location, so powershell resolves even though the Node toolchain remains MSYS2-native. That does not imply the two Node/npm stacks should converge.

So the corrected boundary is:

• node, npm, and their native addons may be MSYS2/MINGW builds;
• powershell.exe may still be callable through the Windows paths exposed in MSYS2's PATH;
• a package published with native addons or Windows-specific launcher assumptions must explicitly support that mixed boundary; native Windows success alone does not prove MSYS2 compatibility.

I checked the linked Handbook Windows guide as well: it describes the native Windows path and PowerShell discovery, but does not currently claim MSYS2 should resolve the same Node/npm shim. I will keep MSYS2 labeled as a distinct compatibility target rather than folding it into native Windows.

[fufurobot]

the native-shell runs normally on my device. the issue is indeed an MSYS2 launcher compatibility issue.

here is my output from MSYS2:

fufu@gpdwin4 CLANG64 /c/Users/fufu/Downloads/workspace/poc/deepseek-harnessing
$ which -a node npm npx
/clang64/bin/node
/clang64/bin/npm
/clang64/bin/npx

fufu@gpdwin4 CLANG64 /c/Users/fufu/Downloads/workspace/poc/deepseek-harnessing
$ npx --yes @deepseek-ai/dsh@latest --version
0.1.0-rc.6

fufu@gpdwin4 CLANG64 /c/Users/fufu/Downloads/workspace/poc/deepseek-harnessing
$ 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"}

fufu@gpdwin4 CLANG64 /c/Users/fufu/Downloads/workspace/poc/deepseek-harnessing
$ npx --yes @deepseek-ai/dsh@latest --version; echo $?
0.1.0-rc.6
0

also, I have tried NODE_DEBUG=* npx @deepseek-ai/dsh web and that may help (the umpressed log is about 164MB):

dsh-on-msys2.log.gz

[fufurobot]

bun told me 4 postinstalls that might be blocked.

fufu@gpdwin4 CLANG64 /c/Users/fufu/Downloads/workspace/poc/deepseek-harnessing/clean-install
$ bun add @deepseek-ai/dsh
bun add v1.3.14 (0d9b296a)

installed @deepseek-ai/dsh@0.1.0-rc.6 with binaries:
 - dsh

521 packages installed [59.38s]

Blocked 4 postinstalls. Run `bun pm untrusted` for details.

fufu@gpdwin4 CLANG64 /c/Users/fufu/Downloads/workspace/poc/deepseek-harnessing/clean-install
$ bu pm untrusted
bash: bu: command not found

fufu@gpdwin4 CLANG64 /c/Users/fufu/Downloads/workspace/poc/deepseek-harnessing/clean-install
$ bun pm untrusted
bun pm untrusted v1.3.14 (0d9b296a)

.\node_modules\@deepseek-ai\dsh-subprocess-local @0.1.0-rc.6
 » [postinstall]: node scripts/ensure-spawn-helper.mjs

.\node_modules\koffi @3.1.5
 » [install]: node ./cnoke.cjs -P . -D src/koffi --prebuild --release

.\node_modules\@google\genai @1.52.0
 » [preinstall]: echo 'preinstall: no-op'

.\node_modules\protobufjs @7.6.5
 » [postinstall]: node scripts/postinstall

These dependencies had their lifecycle scripts blocked during install.

If you trust them and wish to run their scripts, use `bun pm trust`.

It seems that some tricks inside scripts/ensure-spawn-helper.mjs may not work properly on MSYS2.

[fufurobot]

the native-shell runs normally on my device even without the post-installing of the MSVC toolchain. I believe it is an path resolving issue on MSYS2 before pwsh tool loaded. It is likely dsh or its dependency detects windows environments therefore assumes windows-style paths, not msys2-style paths (i.e. C:\foo\bar instead of /c/foo/bar).

[fufurobot]

It works when i uninstall nodejs and use msys2_shell.cmd -clang64 -use-full-path to start a new shell to inhert system PATH variable by npx and bunx installed by system npm. so it is likely there are some patches for mingw-w64-nodejs or patches for mingw-w64-python which makes the nodejs/python toolchain 'believes' that it is working on an Unix shell but windows, which is not true for dsh. Anyway, I wish dsh can detect MSYS2 variables by the env variable MSYSTEM_PREFIX or something else after digging into these patches and use msys2-style paths instead of windows-style variable solving and path (better if calling unix-like shells directly on msys2 to introduce full unix-like shell power on windows).