dsh-mobile boot crashes on Windows when a GNU coreutils whoami.exe shadows System32 in PATH

[iiijiashu]

Environment

• Windows 11 (10.0.26200), dsh web profile (@deepseek-ai/dsh, dsh web)
• Git for Windows installed; its usr/bin directory sits before System32 in PATH (any MSYS2/Cygwin/scoop-coreutils setup does the same)

Symptom

dsh web crashes at boot:

Error: dsh: plugin tree failed to load: failed to apply loader entry mobile-access (dsh-mobile):
Command failed: whoami.exe /user /fo csv /nh
whoami: extra operand '/user'
Try 'whoami --help' for more information.

The whole web profile fails to load — no UI, no 3080 listener.

Root cause

dsh-mobile/lib/index.mjs and dsh-mobile/lib/cli.js resolve the current Windows user SID via:

userSidTask ??= execFileText("whoami.exe", ["/user", "/fo", "csv", "/nh"], { ... })

The bare "whoami.exe" is resolved through PATH. When a GNU coreutils whoami.exe (Git Bash / MSYS2 / Cygwin) precedes System32, the wrong implementation is invoked; it does not accept /user, the call fails, and — because a single loader-entry failure aborts the whole plugin tree — the entire profile boot crashes.

Suggested fix

Invoke the Windows built-in by absolute path instead of relying on PATH resolution, e.g.:

execFileText(join(process.env.SystemRoot ?? "C:\Windows", "System32", "whoami.exe"), ["/user", "/fo", "csv", "/nh"], ...)

Related hardening suggestion: a single (non-critical) plugin failing to load should degrade rather than abort the entire plugin tree boot — this failure mode turns a per-plugin issue into a total outage of the web UI.

(Worked around locally by patching the two call sites to use the absolute System32 path; happy to provide more details if useful.)

[PerryLink]

你的根因判断我认同，而且你那条"加固建议"指向了一个真实的层次差异

1. 现象与你的解释自洽

报错里 whoami: extra operand '/user' 是 GNU coreutils 版 whoami 的措辞（它不接受 /user /fo csv /nh 这些 Windows 参数）——也就是说被调起来的不是 System32 的 whoami.exe，而是 PATH 上更靠前的那个。Git for Windows / MSYS2 / scoop 的 usr/bin 排在 System32 之前时必然复现。这一点你的判断没问题。

⚠️ 一处我这边核不到：我在本仓 packages、apps 全树检索 whoami 字面量没有命中（唯一出现是沙箱文档里谈受限令牌下 cmdlet 会失败的那条，与此无关）。所以那句命令不在本仓可见源码里——它应当来自提供 mobile-access 的那个包（dsh-mobile）。请补一句它来自哪个包/哪个安装位置，否则维护者会先去找不到出处。

2. 你那条加固建议，我认为指对了层次

你写"单个（非关键）插件加载失败应当降级，而不是中止整棵插件树"——这条我有独立依据支持，因为 DSH 里存在两套严厉程度不同的判定：

• 加载期：条目 apply 抛错 ⇒ 你遇到的 plugin tree failed to load: failed to apply loader entry mobile-access（中止）；
• 结算后的审计（auditStartupEntries）：只有必需的条目（requiredStartupEntryIds 里那几个，加上 bootstrap Include）才会致命，其余只警告。

⇒ 也就是说："非关键条目失败不致命"这个原则在审计阶段是成立的，但在加载阶段不成立。你的诉求本质是把这条原则前移到加载期——这是一个有依据、可评审的提法，建议这样写。同一类"故障隔离"问题在别处也有报告（#7865 是工具挂载失败连坐整个会话创建）。

3. 现在能用的规避

把 Git for Windows 的 usr/bin 移到 System32 之后（或从该会话的 PATH 里摘掉）。这是你那条问题的直接解法，且不需要改代码。

4. 版本提醒

你在 dsh web + 0.1.7-rc.2（据你环境）——那就是当前最新（tag dsh-v0.1.7-rc.2），无需先升级。⚠️ 只是别把核换成 npm 的 latest（仍停在 0.1.5-rc.3，更旧）：

npm i -g @deepseek-ai/dsh@next

[iiijiashu]

补充一下具体出处，我刚在出问题的这台 Windows 机器上核过： - 这段逻辑确实不在 deepseek-harness 主仓，而是在独立包 `dsh-mobile`。 - 当前 Web profile ***@***.***` - 安装位置：`C:\Users\17918\.dsh\profiles\web\node_modules\dsh-mobile` - CLI shim：`C:\Users\17918\.dsh\profiles\web\node_modules\.bin\dsh-mobile.cmd` - 实际 CLI 入口：`C:\Users\17918\.dsh\profiles\web\node_modules\dsh-mobile\lib\cli.js` - 包的 repository 字段指向：`https://github.com/saya-ch/dsh-mobile.git` 还有一个值得补充的现象：我现在磁盘上的 ***@***.***` 已经不是依赖 PATH 去找 whoami 了。当前代码里： - `lib/cli.js:38` 调的是 `process.env.SystemRoot + "\\System32\\whoami.exe"` - `lib/index.mjs:823` 也是同样的绝对路径 - 对应上游 `saya-ch/dsh-mobile` 的 `src/private-file.ts` 目前也会把 `whoami.exe` 解析到 System32。 所以原始的 `whoami: extra operand '/user'` 与“当前磁盘上的 0.4.0”状态不一致。更准确地说，那个报错应当来自更新/修复前的 dsh-mobile bundle、旧加载状态或另一份副本；我目前还没有证据把这三种情况进一步区分，先不下结论。 当前 `dsh web` 进程是 2026-09-27 01:03 启动的，而上述 dsh-mobile bundle 文件时间是 2026-09-25 15:01，因此当前这次进程应当已经加载到绝对 System32 路径的版本。 另外我仍然认为加载期的故障隔离值得单独处理：即使某个非 required 的 mobile-access 插件自身出错，也不应把整棵 plugin tree / Web 启动一起打死；和你说的 auditStartupEntries 语义保持一致会更合理。 感谢你指出出处缺失。

…

On Sat, 26 Sep 2026 00:07:35 -0700, PerryLink ***@***.***> wrote: 你的根因判断我认同，而且你那条"加固建议"指向了一个真实的层次差异 1. 现象与你的解释自洽 报错里 whoami: extra operand '/user' 是 GNU coreutils 版 whoami 的措辞（它不接受 /user /fo csv /nh 这些 Windows 参数）——也就是说被调起来的不是 System32 的 whoami.exe，而是 PATH 上更靠前的那个。Git for Windows / MSYS2 / scoop 的 usr/bin 排在 System32 之前时必然复现。这一点你的判断没问题。 ⚠️ 一处我这边核不到：我在本仓 packages、apps 全树检索 whoami 字面量没有命中（唯一出现是沙箱文档里谈受限令牌下 cmdlet 会失败的那条，与此无关）。所以那句命令不在本仓可见源码里——它应当来自提供 mobile-access 的那个包（dsh-mobile）。请补一句它来自哪个包/哪个安装位置，否则维护者会先去找不到出处。 2. 你那条加固建议，我认为指对了层次 你写"单个（非关键）插件加载失败应当降级，而不是中止整棵插件树"——这条我有独立依据支持，因为 DSH 里存在两套严厉程度不同的判定： - 加载期：条目 apply 抛错 ⇒ 你遇到的 plugin tree failed to load: failed to apply loader entry mobile-access（中止）； - 结算后的审计（auditStartupEntries）：只有必需的条目（requiredStartupEntryIds 里那几个，加上 bootstrap Include）才会致命，其余只警告。 ⇒ 也就是说："非关键条目失败不致命"这个原则在审计阶段是成立的，但在加载阶段不成立。你的诉求本质是把这条原则前移到加载期——这是一个有依据、可评审的提法，建议这样写。同一类"故障隔离"问题在别处也有报告（[#7865](#7865) 是工具挂载失败连坐整个会话创建）。 3. 现在能用的规避 把 Git for Windows 的 usr/bin 移到 System32 之后（或从该会话的 PATH 里摘掉）。这是你那条问题的直接解法，且不需要改代码。 4. 版本提醒 你在 dsh web + 0.1.7-rc.2（据你环境）——那就是当前最新（tag dsh-v0.1.7-rc.2），无需先升级。⚠️ 只是别把核换成 npm 的 latest（仍停在 0.1.5-rc.3，更旧）： npm i -g @***@***.*** — Reply to this email directly, [view it on GitHub](#7835?email_source=notifications&email_token=CE3T44N5SLW2DFKS3ECOITT5Q5TLPA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBWGA4TINZYUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18609478), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/CE3T44K2G6XR5ZIKM7VOKFT5Q5TLPAVCNFSNUABJKJSXA33TNF2G64TZHMYTGMZTGA3DKMBZGE5UI2LTMN2XG43JN5XDWMJQHA4DKMJYGKQXMAQ). Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for [iOS](https://github.com/notifications/mobile/ios/CE3T44PWFVZWVYZL4KKQG735Q5TLPA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBWGA4TINZYUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM) and [Android](https://github.com/notifications/mobile/android/CE3T44PKVRYEORNLTCEEHZ35Q5TLPA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBWGA4TINZYUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE). Download it today! You are receiving this because you authored the thread.