[Bug] 第三方 Electron 宿主（Electron-as-node）下 dsh 全量启动失败：require-builtin 指纹门补丁精确 + app-boot 无 --expose-internals 回退

[BiBoyang]

现象

在把 Electron 二进制当 node 用的宿主环境里（实测：Kimi 桌面 Electron 43.7.3 / Node 24.21.0 / V8 15.0.245.31-electron.0），dsh 0.1.7-rc.2 与 0.2.1-alpha.1 的任何 profile 启动即 fatal，与 profile 内容无关（健康内置 profile 同样失败）：

dsh: fatal uncaught exception: Error: dsh: host preparation failed:
node-addon-require-builtin unsupported: Unsupported/no-context
(unsupported Electron runtime fingerprint: Node 24.21.0, V8 15.0.245.31-electron.0
(supported Electron versions: 43.0.0, 44.0.0, 45.0.0-alpha.6))

根因链（均已本机实测）

1. 指纹门的位置与引入版本。 node-addon-require-builtin 的预编译二进制（darwin-arm64-napi-v9.node）内含 Electron 运行时指纹校验，在 requireBuiltin() 调用时触发（getBindingInfo() 不触发）。strings 取证：0.1.5 二进制无任何指纹逻辑，0.1.6（2026-09-14）起存在，0.1.7 同。

2. 白名单是补丁级精确，报错文案却写大版本。 二进制内白名单为三个精确 V8 指纹（15.0.245.13 / 15.2.124.13 / 15.4.80 的 -electron.0 变体）。双向实测闭环：

• Electron 43.0.0（V8 恰为 15.0.245.13-electron.0）→ requireBuiltin('fs') 通过；
• Electron 43.7.3（V8 15.0.245.31-electron.0，同 43 大版本）→ 拒绝。

报错文案 (supported Electron versions: 43.0.0, 44.0.0, 45.0.0-alpha.6) 与行为不一致。

3. --expose-internals 救不了。 dsh 内部有两条获取 Node 内部模块的路径：

• cordis-plugin-loader 的 requireInternal() 认 --expose-internals（有 flag 走官方 require——实测在该 Electron 下 require('internal/modules/cjs/loader') 成功）；
• 但 @deepseek-ai/dsh-app-boot 的 internalModules()（lib/index.js 与 lib/worker/profile-resolution-bootstrap.js 内各 5 处直调 requireBuiltin）不查 flag、无 try/catch，启动路径绕过全部回退。实测加 flag 仍 fatal。

门的动机（理解其合理性）

0.1.5 及之前在 Electron patched Node 下是缺符号崩溃——实测 0.1.5 在上述 Kimi Electron 下报 Unsupported/no-realm (no compatible GetAlignedPointerFromEmbedderData symbol found)。门把静默崩溃变成响亮报错，方向是对的；问题在「补丁精确 + 文案误导 + CLI 无回退」的组合。

影响面

任何把自家 Electron 二进制暴露为 node 的 agent 宿主（Kimi 桌面已实锤；机制上门只读 process.versions，与具体宿主无关），其派生会话内 dsh 全命令启动即败。普通 Node 运行时不受影响（Node v25.4.0 实测正常；二进制内有 untagged Node 20/22/24 family 放行条目）。

补充：同一变量、两个方向 —— "Electron-as-node" 边界双向破损

本 Issue 是内向方向：第三方 Electron 宿主 → dsh 作为子进程继承宿主运行时指纹 → 指纹门 fatal。

经 PerryLink 提示（见本串讨论）存在镜像的外向方向并已由其核实：DSH 桌面端 spawn 外部应用时将 ELECTRON_RUN_AS_NODE=1 透传给 VS Code/Cursor 等，使其以纯 Node 模式启动失败。我对该方向的源码机制做了复核（master @ 5badb150）：packages/host/open-in-app/src/resolver.ts:80 以 scrubbedParentEnv() 为子进程基础环境，而该 scrub（packages/subprocess/subprocess/src/index.ts:47,66-80）只剔除 credential 形态（KEY|PASSWORD|SECRET|TOKEN）与 DSH_* 变量，不剔除 ELECTRON_RUN_AS_NODE；resolver.ts:584 的显式 ELECTRON_RUN_AS_NODE: '1' 是 argv 拉起 CLI 助手的有意用法，与透传无关。

两个方向共享同一变量、同一条边界，建议一并纳入优先级评估。

最小复现

ELECTRON_RUN_AS_NODE=1 <任一非白名单 Electron 二进制> <dsh 的 bin.js> --profile headless "say hi"
# => dsh: fatal uncaught exception: ... unsupported Electron runtime fingerprint ...

修复建议（按推荐序）

1. app-boot 的 internalModules() 复用/对齐 cordis-plugin-loader 的 requireInternal()（--expose-internals 时走官方 require）——改动局部、不碰安全模型，直接救活第三方 Electron 宿主；
2. 报错文案诚实化（写明补丁精确指纹），或真按大版本放行（需安全评估）；
3. 增加 opt-in 环境变量逃生门（默认 fail-closed 不变）。

环境

• dsh：0.1.7-rc.2、0.2.1-alpha.1（npx 发布包）均复现
• 宿主运行时：Kimi 桌面 Electron 43.7.3（Node 24.21.0，V8 15.0.245.31-electron.0）；对照 Electron 43.0.0 通过
• macOS arm64

[PerryLink]

这条是我此前核实过的那一族"反向版本"——同一个变量，方向相反

1. 关系（先说清，因为它决定了该找谁修）

我此前核实过一族报告：DSH 桌面端把 ELECTRON_RUN_AS_NODE=1 透传给外部应用，使 VS Code/Cursor 之类以"纯 Node 模式"启动而失败（代码在 packages/host/open-in-app/src/resolver.ts:80 与 :584）。

⇒ 你这条是它的镜像：DSH 自己作为子进程跑在第三方的 Electron 宿主里（Kimi 桌面 / Electron 43.7.3）⇒ 于是 DSH 继承了宿主的 Electron 运行时指纹 ⇒ 触发 node-addon-require-builtin 的指纹门。

⇒ 建议把这层关系写进摘要：同一变量、两个方向，说明"Electron-as-node"这条边界当前是双向破损的——这会显著提高它的优先级。

2. 你的诊断（我认同它的形态，但需要你补证据）

你写"require-builtin 指纹门补丁精确 + app-boot 无 --expose-internals 回退"。⇒ 这个判断的形态是对的（指纹门过严 + 缺少回退），而且严重度也是对的：你写 0.1.7-rc.2 与 0.2.1-alpha.1 都失败、且与 profile 无关（健康内置 profile 同样失败）⇒ 这不是配置问题，而是硬性兼容墙。

建议把诉求写成：

遇到未知的 Electron 运行时指纹时不应直接 fatal：应当（a）尝试回退路径（例如以 --expose-internals 或等价的显式通道重建 require-builtin 能力），或（b）给出可操作的说明（指出需要哪个运行时/如何规避），而不是让任何 profile 都起不来。

"给可操作说明"是低成本的那一半：即使暂时无法支持该宿主，也应当告诉用户"你的宿主不被支持，请改用官方运行时"。

3. 请补三样

1. 完整错误原文（你贴的是前几行，unsupported Electron runtime fingerprint: Nod… 被截断 ⇒ 后面的指纹串很关键）；
2. 是否只有第三方 Electron 宿主失败（用官方桌面端/纯 Node 跑同一 profile 是否正常）⇒ 这一步把"宿主指纹"钉死；
3. 宿主与运行时版本对照（Electron / Node / V8，你已给 Electron 43.7.3 与 Node 24.21.0 ⇒ 请补 V8 那一段与官方桌面端捆绑版本的对照）。

4. 一条边界

我确认的是**"该变量一族"的双向关系**（我核实过 DSH → 子进程那一个方向）。你这条的指纹门与回退缺失以你补的第 1、2 样为准——我没有该宿主环境。

[BiBoyang]

独立复现确认（第二环境全量复跑，全部主张成立）

在另一环境对本文全部实测主张做了独立复跑，结论：机制、触发点、版本引入点、双向闭环全部成立。复跑环境：Kimi 桌面 Electron 43.7.3（本机实测 Node 24.21.0 / V8 15.0.245.31-electron.0，与文中所述逐字符一致）；对照组为官方 Electron 43.0.0 与官方 Node v24.21.0（nodejs.org 二进制）。

复跑结果

1. fatal 逐字复现（0.1.7-rc.2 与 0.2.1-alpha.1 均如此）：

   dsh: fatal uncaught exception: Error: dsh: host preparation failed: node-addon-require-builtin unsupported: Unsupported/no-context (unsupported Electron runtime fingerprint: Node 24.21.0, V8 15.0.245.31-electron.0 (supported Electron versions: 43.0.0, 44.0.0, 45.0.0-alpha.6))
   

2. 触发点确认：同一进程内 getBindingInfo() 正常返回绑定信息，requireBuiltin('fs') 立即抛上述指纹错误。

3. 双向闭环复现：官方 Electron 43.0.0（V8 恰为 15.0.245.13-electron.0）→ requireBuiltin('fs') 通过；Electron 43.7.3（同 43 大版本，V8 15.0.245.31-electron.0）→ 拒绝；官方 Node v24.21.0 → 放行。

4. 一个补充数据点：官方 Node v24.21.0 的 V8 指纹是 13.6.233.17-node.53，不在任何 family 名单仍被放行 —— 佐证门只对 -electron 标签指纹生效。

5. --expose-internals 两条路径确认：带 flag 时官方 require('internal/modules/cjs/loader') 成功；同 flag 启动 dsh 仍 fatal。源码计数：dsh-app-boot/lib/index.js 与 lib/worker/profile-resolution-bootstrap.js 各 5 处直调 requireBuiltin，全包 0 次查询 flag；cordis-plugin-loader/lib/index.js:11 确查 process.execArgv.includes("--expose-internals")。fatal 栈亦显示调用链为 internalModules ← installRuntimeInterception ← PluginPackages，与修复建议①的落点一致。

6. 版本引入点确认：npm pack 对比 addon 历史版本 —— 0.1.5 二进制 0 个 "electron" 字符串；0.1.6 起出现三个精确指纹与报错文案。npm 记录 addon 0.1.6 发布于 2026-09-14 UTC，与文中日期一致。

7. 0.1.5 对照复现：钉 addon@0.1.5 后在本机 Electron 下 requireBuiltin('fs') 抛出 Unsupported/no-realm (no compatible GetAlignedPointerFromEmbedderData symbol found)，逐字一致。

两处文字建议（不影响结论）

• "二进制内有 untagged Node 20/22/24 family 放行条目"：该字符串在 addon 0.1.5（无指纹门）中已存在，属于符号探测机制（SlowGetAlignedPointerFromEmbedderData(untagged)），并非门的放行逻辑，建议删去这一括号推断；行为结论（普通 Node 不受影响）本身成立。
• 0.1.5 的"缺符号崩溃"在单元级表现为可捕获的 Error 抛出（非段错误），建议措辞为"缺符号错误"。

[codex-zhu]

追加一个数据点：Electron 43.4.0（macOS x64）同样被指纹门拒绝

环境

• 宿主：huangj17/deepseek-harness-desktop v0.2.12 内置 Electron 43.4.0（Chrome 150.0.7871.224），macOS 14.8 / x64，走 darwin-x64-napi-v9 预编译产物
• 运行时指纹：Node 24.18.1 / V8 15.0.245.28-electron.0
• dsh：0.1.7-rc.2、0.2.0-rc.2、0.2.1-rc.2 三个内核启动即 fatal；同机内置的 0.1.0-rc.6（loader 0.1.4）正常启动

报错（0.2.1-rc.2，随包 loader 0.1.9）

dsh: fatal uncaught exception: Error: dsh: host preparation failed:
node-addon-require-builtin unsupported: Unsupported/no-context
(unsupported Electron runtime fingerprint: Node 24.18.1, V8 15.0.245.28-electron.0
 supported Electron versions: 43.0.0, 44.0.0, 44.7.0, 45.0.0-alpha.6)

对主帖的两点补充

1. 白名单在 loader 0.1.9 里扩过一次：主帖记录的是 43.0.0, 44.0.0, 45.0.0-alpha.6，0.2.1-rc.2 自带的 0.1.9 已是 43.0.0, 44.0.0, 44.7.0, 45.0.0-alpha.6——说明维护方确实在按补丁版逐个补表，只是 43.4.0 / 主帖的 43.7.3 还没进。
2. --expose-internals 无效已复现：我按该桌面壳的真实启动命令（Electron --expose-internals <bin.js> web --patch <patch.yml>）执行，报错一字不变，与主帖第 3 点（app-boot 的 internalModules() 不查 flag）一致。

最小复现

ELECTRON_RUN_AS_NODE=1 "/Applications/DeepSeek Harness.app/Contents/MacOS/DeepSeek Harness" \
  <dsh>/lib/bin.js web --host 127.0.0.1 --port 5199 --no-open

这是真实用户路径，不是构造用例

该桌面壳的「检查 Harness 更新…」直接取 registry.npmjs.org/@deepseek-ai/dsh/latest（现为 0.2.0-rc.2），校验通过即激活、提示重启——但激活后的内核在这层 Electron 上起不来。

本机 harness-runtimes/0.2.0-rc.2/ 目录仍在，而决定激活版本的 harness-runtime.json 已不存在，看起来是更新失败后手工回退的残留；该壳 v0.2.12 是当前最新发布（2026-09-09），没有可换的新壳。也就是说这条 Electron-as-node 路径上没有可用的 dsh 版本：旧内核能起但插件生态（最低要求 0.1.5-rc.1+ 的插件）跑不了，新内核能配插件但起不来。

请求

1. 把 Electron 43.4.0（Node 24.18.1 / V8 15.0.245.28-electron.0，darwin-x64） 纳入白名单；
2. 若白名单要保持补丁级精确，希望主帖建议 1（app-boot 的 internalModules() 对齐 cordis-plugin-loader 的 requireInternal()，--expose-internals 时走官方 require）能排上——这对第三方 Electron 宿主是唯一不回退安全模型的活路。