[Bug] 桌面端启动不可恢复：每次启动铸一枚 30 天 dsh-auth-* cookie，约 70 次后 Cookie 头越 16 KB → 431 → "desktop welcome: Web authentication failed"

[Xmiss9]

TL;DR

@deepseek-ai/dsh-desktop 每次启动都给 127.0.0.1 铸一枚 30 天有效、名字里带 authority（含端口） 的认证 cookie，而 Chromium 的 cookie 库只按 host 隔离、不按端口隔离 —— 于是每启动一次永久多一条，永不回收。累积到 71 条时，发往 Host 的 Cookie: 头达到 16,316 B，越过 Node 默认 maxHeaderSize = 16,384 B，Host 在任何鉴权代码执行前直接回 431；桌面壳的 net.fetch 拿到非 2xx，抛出 desktop welcome: Web authentication failed，窗口停在 DeepSeek Harness is unavailable，且每次重试只会再加一条，永远无法自愈。

修法最省事的只有一句：启动握手前把不属于本次 token 的 dsh-auth-* cookie 删掉（把 jar 锁死在 1 条）。

---

环境

App	@deepseek-ai/dsh-desktop 0.2.1-rc.2（内含 @deepseek-ai/dsh-desktop-runtime 0.2.1-rc.2）
OS	Windows 11 x64
Electron / Node	44.7.0 / 24.21.0
安装路径	D:\X\xxrj\DeepSeek（打包版，resources/app.asar）
userData	%APPDATA%\@deepseek-ai\dsh-desktop
第三方插件	有装若干，但故障与插件无关（下文有对照证据）

现象

窗口文案：

DeepSeek Harness is unavailable
The application could not start or stopped unexpectedly.
desktop welcome: Web authentication failed

对话框里的 Restart、Disable third-party plugins, back up profile patch, and restart 全部无效。

崩溃日志（logs\crash-2026-10-24T00-59-41-903Z-host.log，4 分钟内 6 份，内容逐字相同）：

time: 2026-10-24T00:59:41.903Z
source: host
phase: startup
app: @deepseek-ai/dsh-desktop 0.2.1-rc.2
electron: 44.7.0
node: 24.21.0

--- error ---
Error: desktop welcome: Web authentication failed
    at connectDesktopWelcome (file:///D:/X/xxrj/DeepSeek/resources/app.asar/lib/main.js:8886:31)
    at async Object.start    (file:///D:/X/xxrj/DeepSeek/resources/app.asar/lib/main.js:12195:22)
    at async file:///D:/X/xxrj/DeepSeek/resources/app.asar/lib/main.js:7162:5
    at async file:///D:/X/xxrj/DeepSeek/resources/app.asar/lib/main.js:12313:4

renderer console 无任何 error 输出。

根因

1. DesktopHostProcess.start() 以 --port 0 启动 Host，端口每次随机（本机看到过 3351 / 5093 / 8828 / 14512 …）。

2. dsh-desktop-host/lib/index.js:342 通过 ctx.connection.authenticatedUrl(...) 拿到带 launch token 的 URL 回给 Electron。

3. BrowserAuth.authorizeIndex() 用 token 换 cookie：

   res.writeHead(303, {
     location: "./",
     "set-cookie": sessionCookie(cookieName(authority), value, expiresAt, maxAgeMs / 1e3, secure),
   })

   其中 cookieName(authority) = "dsh-auth-" + base64url(sha256(authority))，而 authority 由 Host 头推出、包含端口；Max-Age=2592000（30 天）、HttpOnly、SameSite=Strict。

4. Chromium 的 cookie 库以 host 为键 → 每次启动端口不同 ⇒ cookie 名不同 ⇒ 不会被覆盖，只会新增；30 天内不清理，且每次请求都会被一起发出去（last_access_utc 全库同一时刻，可佐证「全量发送」）。

5. 累计到 71 条时，Cookie: 头 ≈ 16.3 KB。Host 是 Node http 服务器，默认 maxHeaderSize = 16384，在解析阶段就回 431 Request Header Fields Too Large。

6. 桌面壳两条请求路径差异是关键：

   • authenticateWebHost() 用不带 cookie jar 的 Node fetch（只发一个 token）→ 永远 303 成功；
   • connectDesktopWelcome() 用 net.fetch(...)（credentials: "include"）→ 带上整包 cookie → 431；
   • 而它把任何非 2xx 都翻译成同一句话：

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

   所以 431 被伪装成「认证失败」，日志里看不到状态码。

实测：阈值两边都验证过

单独起同一个 Host（dsh-desktop-host/lib/index.js，随机端口），只改 Cookie: 头大小：

请求头内容	字节	Host 响应
只带刚铸的新 cookie	224 B	200（正常返回 index）
新 cookie + 60 条旧 dsh-auth-*	13 824 B	200
新 cookie + 71 条旧 dsh-auth-*	16 316 B	431
纯 padding（一条 dsh-auth 都不带）	16 002 B	401（正常走鉴权）
纯 padding（同上）	16 302 B	431

两个结论：

1. 60 条仍然 200，71 条直接 431 —— 阈值就是 Node 默认 16,384 B，不是「某一条 cookie 坏了」；
2. padding 对照在 16,302 B 也 431（此时一个 dsh-auth cookie 都不存在）—— 彻底排除签名/值/鉴权逻辑问题，纯粹是请求头尺寸。

失败机型上的 cookie 库现场（%APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies）：71 行，全部 dsh-auth-*，全部 host_key='127.0.0.1'，value 明文约 171–173 B，encrypted_value 长度 0，除此之外库里没有别的内容。

反向验证

• 同一 exe 加 --user-data-dir=<空目录> → 正常进工作区 ⇒ 不是二进制、网络、账号、插件问题，就是 profile 的 cookie jar；
• 只删 Network\Cookies（先备份，其余 profile 一律不动、代码零改动）→ 重启后握手 401 → 200，窗口正常显示会话标题，此后零 crash log。

为什么这是个「不可恢复」的坑

• 自我恶化：每次重试都再铸一条，头只会更长，删不掉就永远起不来；
• 误导性文案：Web authentication failed 让人往账号 / 代理 / 插件 / 重装方向排查，日志里没有 431、没有状态码；
• 对话框兜底无效：Restart 和「禁用第三方插件重启」都绕不过这一层；
• 只有手动删库能救，普通用户不可能想到；而且约 70 次启动后必复发（按每天 ~9–14 次启动，约一周一次）。

补充：浏览器端 dsh web 绑固定端口时不复发（cookie 名不变 ⇒ 每次覆盖同一条），所以这是 desktop 独占路径；不影响任何网站登录态，也不影响 profile / 插件 / 会话。

建议修法（任一条即可堵住，按性价比排序）

1. 启动清理（最小改动，推荐）：host.start() 之前遍历 session.defaultSession.cookies，删掉 127.0.0.1 / localhost 上所有 name 匹配 ^dsh-auth- 且不等于本次 token 的项；jar 从此恒为 1 条。
2. cookie 名去掉端口（或直接用常量名），让新 cookie 覆盖旧的；过期/port 不匹配的旧值本来就会被 isAuthenticated() 正常拒绝，不需要靠「名字不同」来隔离。
3. 持久化 secret 而不是每次随机：代码中已有 credentialKey("client-connection", "browser-session") 这类落点，把 secret 持久化后 cookie 值稳定、名字稳定，覆盖逻辑自然生效。
4. 兜底：Host 端 http.createServer({ maxHeaderSize: 64 * 1024 })；或捕获 431 后清库再重试一次，而不是直接让启动失败。
5. 必做的小事：connectDesktopWelcome() 抛错时带上状态码（... Web authentication failed (HTTP 431)）。这一条是本 bug 里最贵的成本来源。

临时规避（用户侧）

1. 完全退出桌面版（确认任务管理器里没有 DeepSeek Harness 进程）；
2. 备份 %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies（文件在运行中被独占，必须关掉应用才能操作）；
3. 删除该文件（或删掉其中 name LIKE 'dsh-auth-%' 的行）；
4. 重新启动，会自动签发 1 枚新 cookie，恢复正常。

与已有讨论的关系

同一台机器同一原因，社区已有两份报告，本文的增量是把阈值两边直接实测出来（他们是推算）：

• #10632（中文，10-22，作者 Light-EI）
• #10828（英文，10-24，作者 lingxujp，已自带启动前清库的 launcher）

另有第三方同因记录：TommyFang2077/dsh-linux-desktop#40、Minglink/DeepSeek-Harness-Desktop#2（后者的「net.fetch 不读 session cookie store」为第二缺陷的说法与上表矛盾：若成立，1 条 cookie 时就该 401，且只删 cookie 不应能恢复）。

完整复现命令与给上游的报告稿（官方 Issues 已关闭，故另存一份）：Xmiss9/wanwan#1

顺带说明：这台机器上还出现过一次无关的崩溃（bili-native-dsh: 1 signed scheme(s) were refused … sdk-hmac-sha256 (https://snap-access.cn-north-4.myhuaweicloud.com) + ERR_INVALID_STATE: ReadableStream is already closed），属第三方层，仅备注以免与本问题混淆。