[Bug] 桌面版认证 cookie 按启动端口命名且 30 天不过期，无界堆积撑爆 16KB 请求头 → host 返回 431 → 启动崩溃循环（desktop welcome: Web authentication failed）

[miozx]

环境

系统环境

• OS：Windows 11 26h2 专业版 x64，Build 26300（10.0.26300.9711）

• app: @deepseek-ai/dsh-desktop 0.2.1-rc.3

• electron: 44.7.0

• node: 24.21.0 （Desktop Host 内置运行时）

• 渲染进程 UA 中的 Chromium 版本：152.0.7977.130

• 安装方式：官方 NSIS 安装包，路径 C:\Users\<user>\AppData\Local\Programs\DeepSeek Harness

• dsh home：默认 %USERPROFILE%\.dsh（desktop profile，含若干第三方社区插件；已确认与本问题无关）

触发场景

• 日均通过第三方重启工具/手动方式重启 4~5 次，约一个月后越线崩溃；越线后崩溃弹窗 Restart 无限复现，每重试一次堆积 +1

概述

dsh 桌面版每次启动都会向 Electron 持久 cookie 库写入一个名为 dsh-auth-<哈希> 的认证 cookie（Max-Age 30 天）。哈希包含本次启动的随机端口，导致 cookie 名字每次都不同、旧 cookie 永不被覆盖。对重启频率较高的用户（日均启动约 3 次以上，约 20~30 天后），cookie 累积使 Cookie 请求头超过 host 侧 Node http 服务器的 16KB 请求头上限，host 对所有认证请求返回 431 Request Header Fields Too Large，桌面端启动即崩（desktop welcome: Web authentication failed），且崩溃循环自增强：每次失败的重试也会再存入一个新 cookie，因此一旦越线永远无法自愈，只能手动清库。

该问题与第三方插件无关，由 host 的 cookie 设计直接导致；Windows / Linux 均可复现。

复现步骤

自然复现：30 天内启动超过约 65~71 次（本次事故实测第 71 条时崩溃；社区独立对照测得 60 条通过、71 条崩溃）。

快速复现：

1. 完全退出 dsh；
2. 用任意 SQLite 工具打开 %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies（Windows），向 cookies 表插入约 70 行记录：host_key='127.0.0.1'、name 各不相同且以 dsh-auth- 为前缀（模拟历史堆积），其余字段取任意合法值；
3. 启动 dsh → 必现崩溃弹窗。

观察证据：以 DeepSeek Harness.exe --log-net-log=netlog.json 启动，netlog 中可看到：

GET /?token=… HTTP/1.1
Host: 127.0.0.1:59992
Cookie: [16186 bytes were stripped]
→ HTTP/1.1 431 Request Header Fields Too Large

当前行为

1. host 下发的认证 cookie（实测抓包）：

   set-cookie: dsh-auth-pzDqTHW_cTsT67AFxO3IWNwUeDqn4cvK0rqqJSgrLP8=
     v1.eyJ2ZXJzaW9uIjoxLCJhdXRob3JpdHkiOiIxMjcuMC4wLjE6NTA2MjkiLCJpc3N1ZWRBdCI6…fQ.<签名>;
     Max-Age=2592000; Path=/; HttpOnly; SameSite=Strict
   

   value 解码后为 {"version":1,"authority":"127.0.0.1:50629","issuedAt":…,"expiresAt":…} —— authority 已在 value 中，名字里再哈希一次端口纯属冗余，却带来了"每次启动新增一个 cookie"的副作用。

2. 崩溃时统计持久库：共 71 个 cookie，全部是 dsh-auth-*，71 个名字互不相同，平均每个在请求头中占 ~228 字节，Cookie 头合计 16186 字节，加上 Host/UA 等其余头后超过 16384（Node 默认 max-http-header-size）。

3. Electron 主进程启动流程 connectDesktopWelcome（lib/main.js:8886）对该请求只检查 response.ok，收到 431 即抛错，桌面端进入崩溃弹窗：

   Error: desktop welcome: Web authentication failed
       at connectDesktopWelcome (…/app.asar/lib/main.js:8886:31)
   

4. 自增强：即使最终 431，首个 303 响应携带的新 set-cookie 已写入持久库，所以每次失败重试（崩溃弹窗 Restart、手动重开、第三方重启工具）都会使堆积 +1，问题不可逆。

期望行为

启动流程不应受历史 cookie 累积影响，认证 cookie 不应无界堆积。建议任选其一（均可根治）：

1. 改为会话 cookie（去掉 Max-Age/Expires）：该 cookie 只需存活单次运行——渲染进程对 host 的所有请求都经主进程转发并手动附带 cookie 头（set-cookie 本就对 renderer 屏蔽），不依赖持久 jar；每次启动 ready.url 都带新 token 重新认证。此项改动最小。
2. 固定 cookie 名（如 dsh-auth）：Chromium cookie 按 host 存储、本就不区分端口，固定名每次启动会被重签的 cookie 自然覆盖；实测带不带 cookie 访问 ?token= 均返回 303 + 新 cookie，旧 authority 残留值不会造成 401。
3. 兜底：主进程在 connectDesktopWelcome 之前清理同 origin 下 dsh-auth-* 前缀的残留 cookie。

临时解决（供社区参考）：完全退出 dsh 后用 SQLite 工具打开上述 Cookies 库执行 DELETE FROM cookies WHERE name LIKE 'dsh-auth-%';。

已有相关讨论（供去重合并）

同一根因（按报告时间排序；均已确认、暂未修复、暂无官方成员回应）：

• #8073（09-27）—— 最早报告：重启数次后 Webview 即 431 不可达，已指出 cookie 名源自 host:port
• #9924（10-17）—— 最活跃主帖（25 条回复）：stale dsh-auth-* 撑爆 Host 头限制（431）
• #10496 / #10550 / #10598 / #10632 / #10634 / #10694 / #10716 / #10794 / #10802 / #10828 / #10868（10-21 ~ 10-24）—— 独立复现潮，其中：
  • #10632：精确阈值对照（60 条通过 / 71 条崩溃）、rc.3 未修确认、Linux 复现
  • #10716：Windows cookie 库路径（…\Network\Cookies）与去 token 边界实测
  • #10598：cookie 作用域不含端口的 HTTP 层机制分析
  • #10694：从"怀疑插件补丁"切入后定位同因（与本帖经历一致）
  • #10828 / #10868：0.2.1-rc.3 复现
  • #10550：含手动清库步骤

相关症状、不同根因（排查时注意区分）：

• #10290 —— 0.2.1-rc.2 打包运行（app.asar）启动必失败、解包正常：同报错文本，但与 cookie 堆积无关

[miozx]

补充：临界值实测与 rc.5 代码级确认

在原帖基础上补充本机（Windows 11 26H2 / 0.2.1-rc.5）的实测数据，供参考与交叉验证。

1. 临界值精确吻合

按 dsh-auth-* 单条 228 字节（name 52 + = 1 + value 173 + 分隔 2）计算：

条数	Cookie 头	距 16384 余量
62	14134 B	2250 B
63	14362 B	2022 B
70	15958 B	426 B
71	16186 B	198 B
72	16414 B	-30 B（超限）

71 条 = 16186 字节，与原帖中 netlog 抓到的 Cookie: [16186 bytes were stripped] 完全一致，也与 #10632 的「60 条通过 / 71 条崩溃」对照吻合。这从算术上闭环了崩溃阈值：72 条起必 431。

2. 本次实测：63 条时已到临界边缘

本机在清理前一刻为 63 条，Cookie 头 14362 字节，余量仅 2022 字节 ≈ 再启动 8 次即越线。按日均 10 次启动计，不到一天就会触线，与「约 25~30 天后崩溃」的普遍描述相比，高频重启用户的实际危险期短得多。

清理前后：

清理前 : 63 条 / 53248 bytes (13 页) / Cookie 头 14362 B / 余量 2022 B
清理后 :  0 条 / 20480 bytes ( 5 页) / Cookie 头     0 B / 余量 16384 B

VACUUM 后库回落到空库基线 20480 字节（5 页）。

3. 新发现：认证 cookie 是明文落盘的

本机库中 encrypted_value 长度全部为 0，173 字符的 cookie 明文直接存在 value 列：

name        : dsh-auth-lfgcYK9U_dloADlTwkyEE5Wczr6mjAZMoCrZaO6JVoU
encrypted_value 长度 : 0
value 长度          : 173
value 前缀          : v1.eyJ2ZXJzaW9uIjoxLCJhdXRob3JpdHkiOiIxMjcuMC4wLjE6NTc3NDkiL...

即 Chromium 的 os_crypt 加密未作用于该 cookie（Local State 中 os_crypt.encrypted_key 存在且 audit_enabled: true）。虽然该 cookie 仅用于本机回环认证、影响面有限，但「本应加密的凭据以明文落盘」与主问题属同一处实现，建议一并核查。

4. 根因的代码级复核（rc.5 仍未修复）

对 0.2.1-rc.5 的 app.asar 复核，原帖列出的三项「期望行为」均未落地：

检查项	rc.5 现状
cookieName(authority) = "dsh-auth-" + base64url(sha256(authority))	仍存在
sessionCookie() 写入 Max-Age	仍存在（cookieMaxAgeDays 默认 30）
启动前清理残留（removeCookies / cookies.remove）	不存在
固定 cookie 名（去端口哈希）	不存在
connectDesktopWelcome 仅校验 response.ok	仍存在（收到 431 即抛 Web authentication failed）

同时验证：库中 62/62 条的名字均满足 name === "dsh-auth-" + base64url(sha256(payload.authority))，且 62 条对应 62 个互不相同的端口，实证「每次启动新增一条、旧条目永不覆盖」。

5. 附：审计 / 清理脚本

为定位本问题写了个小工具（无需依赖，Node 22+ 的 node:sqlite），已在 63 条的真实库上端到端验证：

node cookie-audit.mjs              # 只读审计：条数、Cookie 头字节、余量、还能启动几次
node cookie-audit.mjs --clean      # DELETE dsh-auth-* + VACUUM，体积回落到 20480 B
node cookie-audit.mjs --watch=30 --clean   # 轮询等 DSH 退出后自动清理

需注意两点实测结论：

1. 必须完全退出 DSH。Cookies 库被 Chromium 独占锁定，fs.copyFileSync、File.Open（各 FileShare 组合）、esentutl /y /o、robocopy /B、直接 CreateFileW 全部失败（EBUSY / JET_errFileAccessDenied -1032 / ERROR_SHARING_VIOLATION 32）。
2. copyFileSync 成功 ≠ 可写。文件只读或被共享打开时复制会成功，但 DELETE/VACUUM 抛 SQLITE_READONLY。清理前应实际开一次 BEGIN IMMEDIATE; ROLLBACK 验证写权限，否则容易误判为「已解锁」。

脚本核心逻辑（可直接内联使用）：

// Chromium 时间戳列是 17 位微秒值，超出 JS 安全整数，直接 SELECT 会抛
// "Value is too large to be represented as a JavaScript number"，需 CAST 成 TEXT
const rows = db.prepare(`
  SELECT name, length(value) AS vlen FROM cookies
`).all();

// 精确估算 Cookie 头（Chromium 落盘时 encrypted_value 为空，明文在 value 列）
const auth = rows.filter(r => r.name.startsWith('dsh-auth-'));
const header = auth.reduce((s, r) => s + r.name.length + 1 + r.vlen, 0)
             + Math.max(0, auth.length - 1) * 2;

db.prepare("DELETE FROM cookies WHERE name LIKE 'dsh-auth-%'").run();
db.exec('VACUUM');

6. 一点补充

?token= 认证路径本身没有问题——带不带旧 cookie 访问均返回 303 + 新 cookie，旧 authority 残留不会造成 401。所以根治仍建议优先采纳原帖方案 1（去掉 Max-Age 改为会话 cookie），改动最小且直接消除无界堆积。