[Bug] 桌面端每次启动新发一枚认证 cookie，约 70 次后请求头超过 16 KB，启动直接失败（431 → "Web authentication failed"）

[Light-EI]

环境：DSH Desktop 0.2.1-rc.2 · Windows 11（build 26200）· Node v24.15.0 · 未启用任何第三方插件时同样复现

现象

某次启动弹出：

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」都无效。

崩溃日志（%APPDATA%\@deepseek-ai\dsh-desktop\logs\crash-2026-10-22T05-23-08-752Z-host.log）：

Error: desktop welcome: Web authentication failed
    at connectDesktopWelcome (…/resources/app.asar/lib/main.js:8886:31)
    at async Object.start (…/resources/app.asar/lib/main.js:12195:22)

对应源码：

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

任何非 2xx 都会走到这一句——包括 431。

根因

桌面端认证 token 每个进程启动随机生成一枚：

const COOKIE_PREFIX = "dsh-auth-";
const SECRET_BYTES = 32;
const PROCESS_LAUNCH_TOKENS = new WeakMap();

function processLaunchToken(owner) {
  const existing = PROCESS_LAUNCH_TOKENS.get(owner);
  if (existing !== void 0) return existing;
  const created = encodeBase64Url(randomBytes(SECRET_BYTES));
  PROCESS_LAUNCH_TOKENS.set(owner, created);
  return created;
}

于是：

• 每次启动 → 新 cookie dsh-auth-<base64url>；
• Chromium 存进 %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies（SQLite）；
• 有效期 30 天，旧的不删除、不覆盖、不清理；
• WeakMap 只保证"同一次进程内复用"，跨启动不复用。

累积到约 70 枚时：单枚 name+value ≈ 225 B → Cookie 头 ≈ 16.1 KB；加上 Host / User-Agent / sec-fetch-* 等约 1 KB，总请求头越过 Node 默认 maxHeaderSize = 16384，host 返回 431，主进程看到非 2xx → 抛 Web authentication failed。

实测数据（本机）

项	值
启动失败时的 dsh-auth-* 条数	71
name+value 合计	15,975 B
生成区间	10-17 04:38 → 10-22 05:22
逐日	18 / 22 / 13 / 7 / 8 / 3（平均 ≈14 次/天）
单枚	value 173 B，名字约 40 字符，30 天过期

崩溃发生在第 71 枚出现后的第一次启动。

为什么难自查

报错文案是「Web authentication failed」，看起来像账号/凭据问题。实际上：

• 账号正常、profile 正常、插件无关（禁用全部第三方插件后同样复现）；
• 对话框建议的「重装」和「禁用第三方插件」都不会生效；
• 唯一线索是 host 的 431，但用户侧看不到。

复现步骤

1. 正常启动/退出 DSH 桌面端 N 次；
2. 每次多一条：select count(*) from cookies where name like 'dsh-auth-%' 单调递增；
3. 约 70 次后（取决于其它请求头大小）启动失败。

建议修法（任一即可堵住）

1. 启动时清理：只保留本次 token 对应的 cookie，删掉其它 dsh-auth-*（最小改动）；
2. 每安装一个稳定 secret：代码里已有持久化凭据位置（AUTH_RECORD_KEY = credentialKey("client-connection", "browser-session")），把 secret 持久化，不再按进程随机；
3. 加数量/长度上限：写 cookie 前先清过期项与最旧项，或超过 N 条时清理；
4. 兜底：抬高 host 的 --max-http-header-size，并在超限时给出可读错误而不是「认证失败」。

临时规避

退出 DSH → 删除 Cookies 库中 name like 'dsh-auth-%' 的行（或整库）→ 重启，会自动签发 1 枚新 cookie。

• 只影响桌面端自己的本地认证 cookie，不涉及任何网站登录态；
• profile、插件、会话全部不受影响；
• 备份整库后操作可回滚。

附

• 与 bili / 插件市场等第三方插件无关，纯桌面端认证路径；
• 同一台机器、同一 profile，清空 cookie 后启动恢复正常。

[Loukky]

遇到了同样的问题，清除cookies以后才正常打开。

[Xmiss9]

补一组「直接验证边界」的数据（Windows 端独立复现，与你的结论一致）

同一台机器今天（2026-10-24）踩到完全相同的故障，独立定位到同一个根因，数字和你几乎一致，可以作为交叉验证。

环境：Windows 11 x64 · @deepseek-ai/dsh-desktop 0.2.1-rc.2 · Electron 44.7.0 · Node 24.21.0 · 安装路径 D:\X\xxrj\DeepSeek · userData %APPDATA%\@deepseek-ai\dsh-desktop

崩溃日志与你逐行一致：

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)

4 分钟内连崩 6 次，Network\Cookies 里 71 行，全部 dsh-auth-*，host_key='127.0.0.1'（库里没有别的东西）。

增量：不是推算，是把阈值两边都实测出来了

你（以及 #10828）的 16 KB 结论是算出来的。我这边把它做成了对照实验：单独起同一个 Host（dsh-desktop-host/lib/index.js，随机端口 5093），只改 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 cookie）	16 002 B	401（正常走鉴权）
纯 padding（同上）	16 302 B	431

两个结论：

1. 60 条还完全正常，71 条直接 431 —— 阈值就卡在 Node 默认 maxHeaderSize 16 384 B，与 cookie 数量和命中哪一条无关；
2. padding 对照（一条 dsh-auth 都不带）在 16 302 B 同样 431 —— 彻底排除「某条 cookie 值坏了 / 签名不对 / 鉴权逻辑出错」的可能，就是纯请求头尺寸。

这也解释了为什么只有 net.fetch 那一步失败：authenticateWebHost() 用的是不带 cookie jar 的 Node fetch，只发一个 launch token，所以永远 303 成功；而 net.fetch 会把 jar 里 127.0.0.1 上全部 cookie 一起发出去，先撞 431，connectDesktopWelcome() 的鉴权代码根本没机会执行。

反向验证

• 同一个 exe 起一份 --user-data-dir=<空目录> → 直接进工作区 ⇒ 不是二进制、网络、账号、插件问题；
• 只删 Network\Cookies（先备份，其余 profile 一律不动、代码零改动）→ 重启后握手 401 → 200，窗口正常显示「你好 — DeepSeek Harness」，此后零 crash log。

复发

每启动一次 +1 条、Max-Age=2592000（30 天），删完约 70 次启动后再犯。浏览器端 dsh web 绑固定端口时不复发（cookie 名不变 ⇒ 覆盖同一条），所以这是 desktop 独占路径。

修法补充（在你的四条之外加一条）

你列的四条我都同意，优先第 1 条（启动时只保留本次 token 的 cookie）。再补一条成本几乎为零的：

• connectDesktopWelcome() 抛错时带上 authenticated.status（例如 desktop welcome: Web authentication failed (HTTP 431)）。现在这个文案把所有人往账号 / 代理 / 插件方向带，实际是请求头尺寸——这一点是本次排查里最贵的成本。

相关

• 上游同因讨论：Desktop fails to start with "desktop welcome: Web authentication failed" after ~70 launches (auth cookies accumulate, one per launch, never pruned) #10828
• 我的完整报告（实测表、复现命令、上游 issue 关闭所以放在本仓库）：dsh-desktop 0.2.1-rc.2: startup permanently fails after ~70 launches — accumulated dsh-auth cookies overflow Node's 16KB header limit (431 → desktop welcome: Web authentication failed) Xmiss9/wanwan#1
• 另两处第三方同因记录：TommyFang2077/dsh-linux-desktop#40、Minglink/DeepSeek-Harness-Desktop#2

[ffyfox]

同一问题在 Linux 桌面构建上同样复现（同一 tag v0.2.1-rc.2 + 本地打包补丁），
确认与平台无关：apps/desktop-host/src/index.ts 里就是 --port 0。

一点补充：
rc.3 未修复此问题。0.2.1-rc.3 里 dsh-client-connection 仍是 dsh-auth- + hash(host:port) 命名、Max-Age=2592000，全仓依旧没有清理 dsh-auth-* 的代码。

最小修法仍是：签发时清掉其它 dsh-auth-*，或让 cookie 名不再随端口变化。

[U20205588]

补充：精确崩溃阈值是 65 条（不是“约 70”），另外确认 rc.3 未修
先谢谢 @Light-EI 和 @Xmiss9 —— 我这边独立踩到同一个故障，定位路径和你们一致。下面只补你们没覆盖的三点增量。

1. 临界点是第 65 条，不是“约 70”
   你们的对照是 60 条通过、71 条崩溃，中间留了空档。我把它二分到底了（同一个 Host 进程 dsh-desktop-host/lib/index.js，随机端口，只改 Cookie 条数，Chromium 常规头固定）：

dsh-auth-* 条数
Cookie 头字节
Host 响应
1 229 303
40 9,823 303
60 14,743 303
64 15,727 303
65 15,973 431
66 16,219 431
71 17,449 431
64 条还能启动，65 条必然崩。 单枚约 246 B（52 字符 name + 173 B value + 分隔符），所以触发区间落在 Cookie 头 15,727 B ~ 15,973 B 之间。

这个数字比“约 70”更有用：它意味着只要超过 64 条就该清理了，等到 70 条才开始出问题已经晚了。按 @Light-EI 报的日均 14 次启动，约 4.5 天就会撞线，不是 5 天。

2. rc.3 确认未修复（与 @ffyfox 结论一致，补一条代码级证据）
   我在 0.2.1-rc.2 的 asar 里定位到命名函数本体，dsh-client-connection/lib/index.js:336：

const COOKIE_PREFIX = "dsh-auth-";
// ...
return COOKIE_PREFIX + encodeBase64Url(createHash("sha256").update(authority).digest());
authority 是 host:port，而 apps/desktop-host/src/index.ts 用 --port 0（@ffyfox 已指出），端口每次随机 ⇒ 名字必然每次不同 ⇒ 永不覆盖。写入侧 sessionCookie() 只发 Set-Cookie，全文件搜不到任何 delete / 清理逻辑。

所以第 1 条修法（启动时只保留本次 token）确实是成本最低且唯一干净的。我更倾向第 2 条（secret 持久化）：代码里已经有 AUTH_RECORD_KEY = credentialKey("client-connection", "browser-session") 这个持久化凭据位，把 secret 存进去，cookie 名就恒定了，天然覆盖、永不堆积 —— 而且顺带解决了“重启后旧 cookie 变垃圾”的问题。

3. 一个会咬到所有想写清理脚本的人的坑：DSH 运行期间 Cookie 库根本打不开
   @Light-EI 建议“退出 DSH → 删行 → 重启”，实操时有个坑：Chromium 对这个文件加了独占写锁，连普通只读 open() 都会被拒绝。

我在 DSH 运行中试了四种只读方式，全部失败：

plain open() PermissionError: [Errno 13] Permission denied
mode=ro OperationalError: unable to open database file
mode=ro&immutable=1 OperationalError: unable to open database file
mode=ro&nolock=1 OperationalError: unable to open database file
（immutable=1 通常能绕过 SQLite 锁，但绕不过 Chromium 的文件级独占，所以“只读体检”也必须先关 DSH。）

另外提醒做注入实验的人：条数不要设太高。我把条数推到 120 以上时，Host 直接在 TCP 层 ConnectionResetError (WinError 10054) 掐连接，连 431 都不返回了 —— 如果只看 HTTP 状态码，会误判成“没复现”。

4. 给同病相怜的用户一个现成工具（可选）
   我顺手写了个清理脚本，只删 host_key='127.0.0.1' AND name LIKE 'dsh-auth-%'，其它 cookie 一条不动，删前自动备份、删后 pragma integrity_check 自检：

体检：python clean_dsh_cookies.py --check（需先关 DSH）
清理：python clean_dsh_cookies.py --yes
带故障注入自测：注入到 105% 后能正确判红并清理，恢复后判绿
如果有需要我可以贴出来。但这只是缓解 —— 只要上游不修，每 64 次启动就得跑一次。

最后一条建议（对上游）
@Xmiss9 提的“抛错时带上 authenticated.status”我强烈附议，并且建议再往前一步：在 authenticateWebHost() 或 connectDesktopWelcome() 里显式判断 431，直接给出可读诊断，例如：

desktop welcome: request header too large (HTTP 431) —
127.0.0.1 has 65 dsh-auth-* cookies (15,973 B); delete stale ones from
%APPDATA%@deepseek-ai\dsh-desktop\Network\Cookies and retry