DSH plugin 在 MSYS2 下静默退出 127？改用原生 shell 排查与规避

如果你在 MSYS2 终端（CLANG64 环境）里执行 npx @deepseek-ai/dsh web 或 bunx @deepseek-ai/dsh web，命令立刻退出、没有任何控制台输出，echo $? 得到 127，那么这不是包缺失。 退出码 127 表示「命令未找到」，而它可能由 MSYS 的命令/shim 层在 DeepSeek Harness 的 profile 挂载之前就返回。关键线索是：npx（Node）与 bunx（Bun）都会失败，说明问题不在包运行器，而在 MSYS2 这个混合环境本身（#1624）。

DSH plugin 现象：命令静默退出、退出码 127

这个故障的特点不是「报错」，而是「什么都不说」——没有日志、没有异常、只有一个来自外层的数字。 具体表现：

1. 复现极简：MSYS2 CLANG64 下用 pacman -S $MINGW_PACKAGE_PREFIX-nodejs 装 Node，然后直接运行：

$ npx @deepseek-ai/dsh web

$ echo $?
127

预期是 Web UI 在 http://127.0.0.1:3080 启动，实际是立即静默退出（#1624）。 2. bunx 同样失败：这一点很重要——如果只是 npx 有问题，会怀疑包运行器；但两条路径都失败，就把怀疑面收窄到 dsh 命令自身在该环境下的启动过程（#1624）。 3. 失败发生得很早：「命令静默退出且没有任何错误信息」这个特征，通常指向「失败发生在启动流程的极早期」——也就是还在命令解析层，而不是插件已经跑起来之后（#1624）。 4. 别和另一个 Windows 故障混淆：#197（部分 Windows 10 机器上因 koffi 原生模块崩溃）的退出码是 3221225477 且带有错误信息，与本条完全不是同一失败模式。把它排除掉，能避免在错误方向上排查（#1624）。 5. 后续还出现过另一种完全不同的失败：报告者后来在原生 Command Prompt + 原生 Node 上跑 npx @deepseek-ai/dsh web（0.1.1-rc.2），遇到的是 V8 堆内存耗尽（Ineffective mark-compacts near heap limit / JavaScript heap out of memory），与 MSYS2 的 127 无关。看到这条日志不要误判成本问题（#1624）。

DSH plugin 机制：MSYS2 混合环境的路径解析边界

核心矛盾是「进程被正确识别为 Windows」与「命令发现却是 Unix 风格」这两件事同时成立。 逐层拆解：

1. 官方组合按 process.platform 选工具栈：在 win32 上它会关闭 tool-bash 并启用 tool-pwsh。也就是说，只要 process.platform 是 win32，宿主就会按「你有 PowerShell」来配置工具（#1624）。
2. MSYS2 给出的 node 确实是 Windows 进程：报告者在 CLANG64 下实测：

$ 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

注意两件事：platform 是 win32，而 node 的解析路径却是 MSYS2 的 /clang64/bin/...；同时** --version 能正常返回、退出码 0**。这说明失败不在「Node 能否启动」，而在更后面的某一步（#1624）。 3. 报告者的定位：pwsh 工具加载之前的路径解析问题。他的判断是——dsh 或其依赖检测到 Windows 环境后假定使用 Windows 风格路径（C:\foo\bar），而 MSYS2 提供的是 msys2 风格路径（/c/foo/bar），于是二进制定位失败。这也解释了为什么失败发生在工具栈真正可用之前（#1624）。 4. 安装期脚本也可能是嫌疑点之一：用 bun add @deepseek-ai/dsh 时，Bun 报告有 4 个 postinstall 被拦截，其中 @deepseek-ai/dsh-subprocess-local 的 [postinstall] node scripts/ensure-spawn-helper.mjs 尤其可疑——「spawn helper 的确保逻辑」在 MSYS2 下可能没有按预期生效，而 koffi 的 install 脚本也在被拦截之列。这提示：安装期生成的原生辅助物与运行期路径解析，可能共同参与了这个故障（#1624）。 5. 一个决定性的对照实验：报告者把 MSYS2 自带的 nodejs 卸载、改用 msys2_shell.cmd -clang64 -use-full-path 启动一个新 shell 以继承系统 PATH，然后用系统 npm 安装的 npx / bunx 就能正常运行。这个对照很有价值——它说明问题出在 MINGW 版 nodejs/python 工具链的补丁上：这些补丁让工具链「以为自己在 Unix shell 里、其实在 Windows 上」，而这套假设对 DeepSeek Harness 并不成立（#1624）。 6. 产品侧可行的改进方向：报告者建议宿主通过 MSYSTEM_PREFIX 之类的环境变量识别 MSYS2，并在这种情况下使用 MSYS2 风格路径而不是 Windows 风格变量求解；更进一步，在 MSYS2 上直接调用类 Unix shell，把完整的 Unix shell 能力带进 Windows。这些都属于提高混合环境兼容性的方向，而不是要求用户改变环境（#1624）。

DSH plugin 排查与规避：四条命令分流、原生 shell 运行、版本对齐

先用四条命令把「哪一层失败」切开，再决定是改环境还是等版本。 具体做法：

1. 第一步：判断包自己的 bin 到底能不能执行。在 MSYS2 里跑这四条，并记下每条的输出：

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

判读方式：如果 --version 也返回 127，失败就在 Web 或 Cordis 图启动之前的 npm/MSYS bin 解析层（因为 DeepSeek Harness 的 bin 会在动态导入 profile boot 路径之前先处理 --version）；如果 --version 正常而 web 返回 127，则继续跑 npx --yes @deepseek-ai/dsh@latest --profile web --dump-config，并同时抓取 stdout 与 stderr（#1624）。 2. 第二步：用原生 shell 做控制实验（同时也是当前最实用的规避）。在原生 Windows PowerShell 或 Command Prompt 里、用原生 Windows Node 安装（而不是 MSYS2 pacman 的 Node 构建）执行：

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

如果原生 shell 成功，就基本可以把本问题隔离为 MSYS2 启动器兼容问题，而不是 #197 那种 Windows 原生模块崩溃；如果仍然失败，就把上面四条诊断输出加上 npm --version 一起贴出来，用于判断两个 shell 是否解析到同一个 node.exe 与 npm shim（#1624）。 3. 第三步：另一种已验证的 MSYS2 内变通。卸载 MSYS2 的 nodejs，改用 msys2_shell.cmd -clang64 -use-full-path 启动 shell 以继承系统 PATH，再用系统 npm 安装的 npx / bunx 运行。这条路径实测可用，代价是你不再使用 MINGW 版 Node（#1624）。 4. 第四步：版本对齐。报告者在 2026-09-09 确认 Windows 支持在 0.1.2-rc.1 上恢复，因此先把版本升到该版本或更新再复测是合理的。但要记住他补充的那句：MSYS2 下的 bunx 仍然静默失败——所以即便升级之后，MSYS2 内的 bunx 路径也不能算被验证可用（#1624）。 5. 第五步：别把不同故障混在一起下结论。同一条讨论串里先后出现过三类现象：MSYS2 的静默 127、原生 shell 上的 V8 堆内存耗尽、以及 Linux 下 Bun 的失败日志。它们的时间点与环境各不相同，不能据此判断「Windows 全面不可用」，也不该用其中一个的结论去解释另一个（#1624）。 6. 给插件作者的启示：跨平台插件里凡是依赖外部可执行文件或路径拼接的地方，都要明确「我拿到的是 Windows 路径还是 MSYS2 路径」。当你在 DSH Plugin Hub 上分发这类 DSH插件、或者写需要跨平台的 DeepSeek插件 时，如果它在 MSYS2 或 Git Bash 之类的混合环境里也会静默退出，用户看到的就是一模一样的 127——所以要么显式检测这类环境并给出可读错误，要么在文档里直接写明推荐使用原生 shell（#1624）。

DSH plugin 排查注意事项

先记住 127 不等于包缺失——它可能是 MSYS 的 shim 层在 profile 挂载之前就返回的一个数字，所以先分清「哪一层失败」比急着重装有效得多。 八条要点：

1. 127 ≠ 包缺失：它可能是 MSYS 的 shim 层在 profile 挂载前返回的。
2. 先测 --version：它能区分「bin 解析层失败」与「profile boot 之后失败」。
3. npx 与 bunx 都失败：说明问题在环境/命令本身，不在包运行器。
4. 原生 shell 是首选：组合在 win32 上启用 tool-pwsh 并关闭 tool-bash，混合环境最容易卡在这里。
5. MSYS2 内变通可行但换工具链：继承系统 PATH + 系统 npm 的 npx/bunx。
6. 别和 #197 混淆：那条是 koffi 原生崩溃（退出码 3221225477 且有报错）。
7. 0.1.2-rc.1 起 Windows 支持恢复，但 MSYS2 下的 bunx 仍未被确认可用。
8. 路径风格要显式判断：写跨平台插件时，别默认「Windows 就是 Windows 风格路径」。

来源：Discussion #1624、Windows compatibility guide、Discussion #197。