Bug Report: dsh 0.1.5-rc.1 silently exits on Node.js v24.1.0 / 缺陷报告：dsh 0.1.5-rc.1 在 Node.js v24.1.0 上静默退出

[referiw]

To: DeepSeek Harness Team

---

English Version

Hi DeepSeek Team,

I'm writing to report a compatibility bug in @deepseek-ai/dsh version 0.1.5-rc.1 that causes the CLI to silently exit without any output or error on Node.js v24.1.0.

Environment:

· OS: Windows 11 Pro for Workstations
· Node.js: v24.1.0 (installed via nvm-windows)
· npm: 11.3.0
· dsh: 0.1.5-rc.1 (installed globally via npm)

Symptom:
Running dsh web produces no output, writes nothing to log files, and never binds to port 3080. The process exits immediately with code 0. No error message is shown.

Root Cause:
In lib/bin.js, the entry point is guarded by:

if (import.meta.main) await runCli();

import.meta.main was only introduced in Node.js v24.2.0 (and v22.18.0 on the 22.x line). On Node.js v24.1.0, this property is undefined, so runCli() is never called. The process loads the module, does nothing, and exits cleanly.

Why this is a problem:
The engines field in the published package.json (if present) specifies:

"engines": { "node": "^22.19.0 || >=24.0.0" }

This range includes v24.0.0 and v24.1.0, which lack import.meta.main. Furthermore, the engines field appears to be absent from the published npm package, so npm does not warn or block installation on incompatible Node versions. Users on v24.1.0 get a silent failure with no clue about the version mismatch.

Suggested Fixes:

1. Tighten the engines range to ^22.19.0 || >=24.2.0 and ensure it is included in the published npm package.
2. Or, make the entry point compatible with older Node versions by replacing import.meta.main with a portable check, e.g.:

   import { fileURLToPath } from "node:url";
   if (process.argv[1] === fileURLToPath(import.meta.url)) {
     await runCli();
   }

3. Add a runtime version check at startup that prints a clear error if Node < 22.19.0 or (Node 24.x < 24.2.0).

I spent considerable time debugging this, including checking WDAC policies, native module builds, and proxy settings, before discovering the Node minor version gap. A clear error message or a stricter engines field would save users a lot of trouble.

Thanks for your work on DeepSeek Harness.

---

尊敬的 DeepSeek 团队，

我写信是为了报告 @deepseek-ai/dsh 版本 0.1.5-rc.1 的一个兼容性缺陷：在 Node.js v24.1.0 环境下，CLI 会静默退出，没有任何输出或报错。

环境：

· 操作系统：Windows 11 Pro for Workstations
· Node.js：v24.1.0（通过 nvm-windows 安装）
· npm：11.3.0
· dsh：0.1.5-rc.1（通过 npm 全局安装）

症状：
运行 dsh web 后无任何输出，日志文件为空，也从未监听 3080 端口。进程立即以退出码 0 结束，没有任何错误提示。

根本原因：
在 lib/bin.js 中，入口逻辑由以下代码保护：

if (import.meta.main) await runCli();

import.meta.main 这个 API 直到 Node.js v24.2.0（以及 22.x 系列的 v22.18.0）才被引入。在 Node.js v24.1.0 中，该属性为 undefined，因此 runCli() 永远不会被调用。进程加载完模块后什么都没做，就正常退出了。

为什么这是个问题：
发布包 package.json 中的 engines 字段（如果存在）声明为：

"engines": { "node": "^22.19.0 || >=24.0.0" }

这个范围包含了 v24.0.0 和 v24.1.0，但它们缺少 import.meta.main。更严重的是，实际发布到 npm 的包中似乎根本没有携带 engines 字段，因此 npm 不会对不兼容的 Node 版本发出警告或阻止安装。使用 v24.1.0 的用户只会遇到静默失败，完全无法联想到是版本不匹配导致的。

建议的修复方式：

1. 将 engines 范围收紧为 ^22.19.0 || >=24.2.0，并确保它被包含在发布的 npm 包中。
2. 或者，让入口代码兼容旧版 Node，将 import.meta.main 替换为可移植的判断方式，例如：

   import { fileURLToPath } from "node:url";
   if (process.argv[1] === fileURLToPath(import.meta.url)) {
     await runCli();
   }

3. 在启动时增加运行时版本检查，如果 Node < 22.19.0 或 Node 24.x < 24.2.0，则打印明确的错误信息。

我花了大量时间排查这个问题，包括检查 WDAC 策略、原生模块构建、代理设置等，最后才发现是 Node 小版本号的差异。一个清晰的错误提示或更严格的 engines 字段，可以为用户省去很多麻烦。

感谢你们为 DeepSeek Harness 所做的工作。

[yaotailin]

问题可能在v0.1.5-rc.2修复了，你可以试一试

[referiw]

我已经换了nodejs版本装完了。还没用过rc2，我直接装的latest就是rc1

[referiw]

清华软件开源镜像上的nodejs刚好就到v24.1.0，完美闪退导致我排查了三个小时。这个哥们用24.0的nodejs也遇到了同样的问题 #4047

[Robin1987China]

Your root cause is exactly right, and I confirmed it with real Node binaries rather than by reading the source.

Verified — and a bridge that works today

I reproduced this on real Node binaries and the real published CLI:

Node	import.meta.main	lib/bin.js --version	dsh-compat --version
24.1.0	undefined	(no output, exit 0)	diagnosis + 0.1.5-rc.1
24.2.0	true	0.1.5-rc.1	0.1.5-rc.1
26.7.0	true	0.1.5-rc.1	0.1.5-rc.1

The exact availability boundary is 24.2.0 and 22.18.0 — not "24" as a whole; 24.0.x and 24.1.0 are affected too.

Bridge: dsh-node-compat — npm · GitHub

lib/bin.js already exports runCli, and runCli() reads process.argv.slice(2). The launcher imports that same module, calls runCli() itself, and passes your arguments straight through:

npx dsh-node-compat web
# or: npm i -g dsh-node-compat && alias dsh=dsh-compat

On a runtime where the guard works it is completely silent; on one where it does not, it prints the diagnosis first. It never double-runs, because when the launcher is the main module bin.js sees import.meta.main === false.

The permanent fix is two lines upstream: replace the guard with a check that works on every supported runtime, and declare engines so npm warns at install time. Raw runs are in the repo's docs/verification.md.

---

已用真实环境验证，并提供一个今天就能用的桥

我用真实 Node 二进制与真实已发布 CLI 复现：

Node	import.meta.main	lib/bin.js --version	dsh-compat --version
24.1.0	undefined	（无输出，exit 0）	诊断 + 0.1.5-rc.1
24.2.0	true	0.1.5-rc.1	0.1.5-rc.1
26.7.0	true	0.1.5-rc.1	0.1.5-rc.1

精确的可用边界是 24.2.0 与 22.18.0 —— 不是笼统的「Node 24」；24.0.x / 24.1.0 同样受影响。

桥：dsh-node-compat —— npm · GitHub

lib/bin.js 本来就导出了 runCli，而 runCli() 读取 process.argv.slice(2)。启动器 import 同一个模块、自己调用 runCli()，把你的参数原样透传：

npx dsh-node-compat web
# 或：npm i -g dsh-node-compat && alias dsh=dsh-compat

在守卫正常的运行时上它完全静默；在守卫失效的运行时上，它先打印诊断。它绝不会重复执行 —— 当启动器是主模块时，bin.js 看到的 import.meta.main 是 false。

永久修复是上游两行：把守卫换成在所有受支持运行时上都能用的判断，并声明 engines 让 npm 在安装时就告警。原始运行记录在仓库的 docs/verification.md。

[PerryLink]

复核确认：这是 #6520 清单第 7 条的同族问题（Node 版本无运行时门槛），rc.2 不会修复它——rc.1/rc.2 的入口路径是同一条 master 线。

• apps/cli/src/bin.ts 入口共 66 行，没有任何运行时 Node 版本检查；apps/cli/package.json 没有 engines；
• 只有根 package.json 声明 "node": "^22.19.0 || >=24.0.0"，而 npm 对 engines 只打警告、不拦截——所以 Node 24.1 会"安装成功"然后静默退出，无任何提示。你链接的 [Bug] pnpm run build 静默退出，5 个 CLI 脚本入口不执行（Node 24.0.x import.meta.main 兼容问题） #4047（24.0 同样闪退）是同一族。
• 社区实测口径：可用下限约为 Node 24.2（24.0/24.1 会触发 undefined 类错误），或 22.19+。

规避：升级 Node ≥ 24.2；或全局安装（npm i -g @deepseek-ai/dsh）后直接跑 dsh，绕开 npx 的静默失败路径。
建议方向（与 #6605 的提案一致）：入口加运行时版本守卫，不满足时打印明确的版本要求并以非 0 退出。
已把 #6584 / #6605 补进 #6520 第 7 条的"相关讨论"。