桌面版 0.2.1-rc.2：打包运行（app.asar）启动必失败 desktop welcome: Web authentication failed，解包成目录就正常

[Yuuyuko-uu]

环境

• DSH 桌面版 0.2.1-rc.2，Windows 11 x64
• Electron 44.7.0 / Node 24.21.0
• 装了若干第三方插件（已排除，见下）

现象

以打包形式运行（D:\deepseek\resources\app.asar 存在）时，启动必然失败，连续 10 次全部是同一个错误：

Error: desktop welcome: Web authentication failed
    at connectDesktopWelcome (lib/main.js:8886)
    at async Object.start (lib/main.js:12195)

把同一份 app.asar 解包成 resources/app 目录运行 → 100% 成功，认证返回 303 再 200 OK，主界面正常。

也就是说：问题只在 isPackaged = true 这条路径上出现。现在我还在用解包目录跑，所以这件事"能绕过去但没修好"。

已经排除的可能

1. asar 文件本身没有损坏
   解析它的文件表：18309 个文件、目录结构完整，dsh/node_modules/@deepseek-ai/dsh-desktop-host/lib/cli.js 也在里面。

2. 不是"Electron 读不了 asar"
   用 ELECTRON_RUN_AS_NODE=1 启动 Electron 去读 asar 内部目录，fs.readdirSync 正常返回；普通 node 才读不了（ENOENT）——但桌面启动 host 用的正是 Electron 的 node 模式。

3. 与第三方插件无关
   解包模式下，全部插件（12 个 bundle + 自定义插件）都加载时，启动正常。而且插件报错不会以"认证失败"的形式出现。

4. 「禁用第三方插件」按钮没能真的禁用
   这个按钮只把 profile 的 cordis.patch.yml 清成了 []，
   但插件实际是挂在 package.json 的 dsh.profile.bundles 里的 —— 那一层没有任何改动，点完之后第三方插件照旧全部加载。
   （我留有按钮写的空 patch 备份作证。）

缺失的关键信息

• host 子进程的 stderr 从来没有落盘：crash-*-host.log 里只有外层那一句，host 自己输出什么完全看不到。
  （DesktopHostProcess 里有一个 64KB 的 stderr 环形缓冲，但失败时没有写进 crash log。）
• Windows 应用事件日志在该时间段没有任何错误记录 ⇒ 进程不是崩溃被系统记录，而是被优雅地判定为"启动失败"。

建议（按重要性）

1. 把 host 子进程的 stderr 写进 crash log（失败时把那个环形缓冲 flush 出来）。
   现在"认证失败"这一句把四种完全不同的死因（host 起不来 / 端口没开 / 权限 / 内部抛错）压成了同一句话，用户和插件作者都无从下手。
2. 「禁用第三方插件」应同时清 dsh.profile.bundles，否则它不是一个真正的安全模式，无法用来二分定位。
3. 打包分支（isPackaged=true）与解包分支的差异值得查一下：从现象看，外壳在等后端的 ready URL，但打包时没等到可用的那一个。

现在的临时解法

把 resources/app.asar 改名为 .bak，把它的内容解包成 resources/app/ 目录 —— 之后启动、认证、插件全部正常。
副作用：dsh 命令行工具仍硬编码 app.asar 路径，会报 MODULE_NOT_FOUND（不影响桌面使用）。

---

English summary: On DSH Desktop 0.2.1-rc.2 (Windows), launching from the packaged app.asar always fails at
desktop welcome: Web authentication failed (10/10 attempts), while the same app extracted to a plain
resources/app directory starts fine (303 → 200). The asar is intact, Electron's node mode can read it, and the
failure is unrelated to third-party plugins. The host child process's stderr is never persisted, so the real cause
cannot be diagnosed. Suggested fixes: persist host stderr into the crash log, and make "disable third-party plugins"
also clear dsh.profile.bundles.