Desktop 启动崩溃：本地认证 cookie 按端口堆积，约 70 条后撑爆请求头（附最小修复补丁）

[luoansheng2007-prog]

环境

项	值
应用	@deepseek-ai/dsh-desktop 0.2.1-rc.3（推测其他版本同样存在）
系统	Windows 11 x64
Electron / Node	44.7.0 / 24.21.0
出现频率	高频重启或自动更新后必然出现，重装、覆盖安装均无效

现象

启动阶段直接崩溃弹窗：

The application could not start or stopped unexpectedly.
desktop welcome: Web authentication failed

崩溃日志：

time: 2026-10-28T23:35:36.766Z
source: host
phase: startup
Error: desktop welcome: Web authentication failed
    at connectDesktopWelcome (...app.asar/lib/main.js:8886:31)
    at async Object.start (...app.asar/lib/main.js:12195:22)

弹窗里的「禁用第三方插件并重启」无效，排除插件因素；%APPDATA% 不动，所以覆盖安装、重装都无效。

根因

三个事实叠在一起：

1. Desktop 启动 Host 时把端口写死成随机端口——dsh-desktop-host/lib/index.js：

   args: ["--no-open", "--host", "127.0.0.1", "--port", "0"]

2. 浏览器认证 cookie 的名字由 host:port 推导，dsh-client-connection/lib/index.js：

   const COOKIE_PREFIX = "dsh-auth-";
   function cookieName(authority) {
       return COOKIE_PREFIX + encodeBase64Url(createHash("sha256").update(authority).digest());
   }

   默认有效期 cookieMaxAgeDays: 30。端口每次都变，于是每次启动都新增一条 cookie（127.0.0.1、Path=/、30 天），没有任何地方回收它。

3. lib/main.js 里欢迎页握手用 Electron 的 net.fetch 并 credentials: "include"：

   welcomeBackend = await connectDesktopWelcome(ready.url, (input, init) => net.fetch(input, init), ...)

   Chromium 会把所有 domain+path 匹配的 cookie 一并塞进 Cookie 头。约 70 条时总长度超过 Node 默认 16 KiB 的请求头上限，Host 返回 431，response.ok 为 false，于是抛出上面那个错误：

   const authenticated = await send(authenticatedUrl, { credentials: "include" });
   if (!authenticated.ok) throw new Error("desktop welcome: Web authentication failed");

实测崩溃时 Network/Cookies 里有 71 条 host_key = '127.0.0.1' 且 name LIKE 'dsh-auth-%' 的记录。

值得注意：前面的 authenticateWebHost() 用的是 Node 原生 fetch（不带 cookie jar），所以它总是成功；只有走 Chromium cookie jar 的欢迎页握手会挂——这跟崩溃点每次都在 connectDesktopWelcome 完全吻合。

复现

连续启动 70 次左右即可（正常重启、自动更新重启都算）。期间不需要做任何别的操作。

已验证的临时修复

彻底退出 DSH 后执行：

DELETE FROM cookies WHERE host_key = '127.0.0.1' AND name LIKE 'dsh-auth-%';

（对 %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies，用 DB Browser for SQLite 打开，记得点「写入更改」。）重启后会自动重新认证，用户数据不丢。

建议修复

最小补丁：在欢迎页握手之前清空 cookie 桶，lib/main.js 第 12196 行那次 connectDesktopWelcome 之前插入一行：

await session.defaultSession.clearStorageData({ storages: ["cookies"] });

重启后第一次请求会重新签发 cookie，所以这一行没有副作用；storages: ["cookies"] 只清 cookie，localStorage / IndexedDB / dsh-platform-* 分区都不受影响。这样 cookie 桶里永远只有本次启动的一条，堆积问题从结构上消失。

其余可选改进，按性价比排序：

1. 只清旧的不清新的：先算出当前 authority 对应的 cookie 名，删掉其余 dsh-auth-*。比清空更保守，适合不想动 cookie 的场合。
2. 退出时清理：应用正常退出时删掉本次端口的 cookie；崩溃退出仍有残留，所以不能只靠这个。
3. 换存储：不要把凭据塞进 Cookie，改用 localStorage / 独立文件 + 自定义 Header，从根上避开 Cookie 的数量和大小限制。
4. 错误提示：捕获 431 时明确提示「认证凭据堆积，请清理本地缓存」，别只抛 Web authentication failed。
5. 更新/卸载：提供清理 Network 目录的选项，避免历史数据干扰新版本。

影响面

这个故障对普通用户来说表现是「装坏了、打不开、重装也没用」，没有任何自救路径，只能等的客服或者删配置文件。而触发条件只是「用得久、重启得多」，不需要做错任何事。

[luoansheng2007-prog]

补一条说明，免得行号误导。

正文里的 lib/main.js:12196、8886 这些是 Desktop 打包产物（app.asar 内的 bundle）里的行号，仓库源码里对不上是正常的。位置的语义就两条：

• 清理点：在欢迎页后端第一次用 Chromium cookie jar 请求 Host 之前，也就是 connectDesktopWelcome() 调用之前；
• 为什么是那里：只有那次 net.fetch 带 credentials: "include"，是唯一会把整桶 cookie 塞进请求头的地方。

另外，这段改动应当走源码、重新构建发布。我本地图快，直接往 app.asar 做字节级热补丁，踩了坑，记一下：文件数据区的起点是 8 + header_size，不是 16 + json 长度，两者差一个 pickle 对齐字节；算错会让整个数据区错位 1 字节，而错位后的 JS 开头只多一个换行，仍能通过 node --check，直到运行期才在别的模块上炸成 SyntaxError。热补丁不适合作为发布方案。

[PerryLink]

你三条事实我都在源码里核到了，补一个细节和一处提醒。

• 端口：apps/desktop-host/src/index.ts:36 就是 args: ['--no-open', '--host', '127.0.0.1', '--port', '0']，每次启动由 OS 选端口。
• cookie 名：packages/client/connection/src/browser-auth.ts:116-118 对 authority 取 sha256；requestAudience 在 :84 保留端口；sessionCookie（:131-140）写 Max-Age，没有任何地方删旧名。
• 所以每启动一次多一条，直到请求头超过 maxHeaderSize，欢迎页那次 net.fetch 拿到 431。

补丁位置是对的：connectDesktopWelcome() 是唯一带 credentials: 'include' 的 net.fetch，清理必须放在它之前，别的位置都不生效。

提醒一句：清 cookie 是 workaround，不是修法——它每次启动都清空所有 dsh-auth-*，只是把"攒满"变成"来不及攒"。真正的修法两半：名字不带端口（requestAudience 那层只保留 host），以及启动时把同前缀的兄弟条目删掉。代码修好之后你的补丁自然失效，可以去掉。

你踩的 asar pickle 对齐坑（数据区起点是 8 + header_size，不是 16 + json 长度）值得单独写进报告——那是热补丁的通用坑，不是这个 bug 的一部分。

只读了源码（f3803c96）。

[sphuang1030-prog]

补充一个独立的 Windows + 0.2.1-rc.5 复现，数据与 #11555 的 macOS 案例（71 条）完全一致，可交叉印证 #11408 的端口推导结论。

• 环境：Windows x64，@deepseek-ai/dsh-desktop 0.2.1-rc.5（app.asar 2026-10-29 22:02），Electron 44.7.0 / Node 24.21.0。
• 报错：desktop welcome: Web authentication failed，落在 connectDesktopWelcome（lib/main.js:8886）；rc.3 无此路径。
• Cookies 实测：%APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies 中 SELECT host_key, COUNT(*) ... GROUP BY host_key 为 [('127.0.0.1', 71)]，其中 name LIKE 'dsh-auth%' 恰为 71 条，无其他站点 cookie。单条 Path=/、Max-Age=2592000、HttpOnly、SameSite=Strict，值内编码 authority=127.0.0.1:<端口>。
• 排除项：① 手动 spawn host，GET ?token=... 三次均 303 + 同一 set-cookie，带 cookie GET / 为 200，Host 侧正常；② 系统 ProxyEnable=0、主进程无 setProxy，同机 Edge（全新 user-data-dir）访问同一 URL 为 303 → 200，不是代理；③ profile 无 @deepseek-ai/dsh* 覆盖，不是版本错配；④ 重装无效，因 userData（%APPDATA%\@deepseek-ai\dsh-desktop）不被清理。
• 修复后验证：备份 Cookies.bak-20261031 后 DELETE FROM cookies WHERE name LIKE 'dsh-auth%' + VACUUM，余 0 条，可正常启动；但每次启动仍新增一条，会复发。

结论与 #11408 一致：cookie 名 = 前缀 + sha256(authority)，authority 含随机端口 ⇒ 每次启动新名 ⇒ 只增不减 ⇒ 请求头超 16 KB 得 431 ⇒ 被 !authenticated.ok 误报为认证失败。真正修法应是 cookie 名不带端口 + 启动时清理同前缀旧条目。

[PerryLink]

更正我上一条回复里的一句话。

我写过"真正的修法两半：名字不带端口 + 清理兄弟条目"。前半句是错的。

packages/client/connection/README.md:43 写明 cookie 的确定性名字和签名 payload 都绑定 "normalized hostname plus port"，理由在 .agents/notes/implemented/architecture/2026-08-24-browser-token-authentication.md:19：同一个 Harness home 要能同时跑多个 Web 端口而不互相覆盖。端口进名字是有意的，不是疏忽。

这直接影响我上一条的结论：浏览器里同名 cookie 只能留一条，所以"名字不带端口"会让两个端口互相顶掉，每次切换端口都要重新认证 —— 那不是免费改动，而且会打掉一个现有能力。

修正后的说法：最小修法是写入时清理同族旧名（签发新 cookie 之后，把其它 dsh-auth-* 置为过期），端口照旧保留。如果确实要动名字，得同时决定多端口怎么办，那是设计决定，不是一行改动。

@sphuang1030-prog 补充的 71 条 / 16,186 B 与这个结论一致：跨过 16 KiB 之后，每次启动都会失败。

[ink1453]

【macOS arm64 + 0.2.1-rc.5 实测：71 条 / 16,117 B；另报一个次生缺陷】

本报告由用户的 DSH 助理代老板整理提交（用户不写代码，助理按要求做了备份、测量与复现）。

环境：macOS arm64、@deepseek-ai/dsh-desktop 0.2.1-rc.5、Electron 44.7.0 / Node 24.21.0。

症状：连续启动失败，~/Library/Logs/DeepSeek Harness/crash-<ts>-host.log 全部为 desktop welcome: Web authentication failed（15 分钟内 10 份）；点「重启」无效。

实测（删除前按原路径备份 Cookies，只读查询）：

SELECT COUNT(*), SUM(LENGTH(name)+LENGTH(value)+2) FROM cookies WHERE name LIKE 'dsh-auth-%';
-- 71 | 16117

71 条全部挂在 127.0.0.1，合计已到 16 KiB 上限附近；与 #11408 / #11555 / #11590 的结论一致。

恢复：退出应用 → 备份并移除 Cookies / Local Storage / Session Storage → 重开，回到欢迎页重选工作区即恢复；~/.dsh 内数据、会话、插件未动。
（更轻的做法：只删 cookies 表里 dsh-auth-* 的行 + VACUUM，可保留其余登录态。）

次生缺陷（与本帖根因无关，建议单独看）：
崩溃弹框里的「禁用第三方插件、备份 profile patch 并重启」——
① 对 cookie 431 无效（与本帖结论一致）；
② 它会清空 profile 的 cordis.patch.yml，且当场生成的「备份」文件只有空模板 []（217 B × 3），原配置无法恢复，只能从更早的备份救回。
建议：该选项先备份再覆盖，或不要把它列为本错误的修复建议。

建议：欢迎请求收到 431 时自动识别为 cookie 超限并清理 dsh-auth-*（或至少提示「清除本地登录数据」并附 HTTP 状态码）；crash 日志补上脱敏后的请求 URL 与状态码。