[desktop] dsh-auth-* cookie 无上限累积，约一个月后请求头超 16 KiB 触发 431 崩溃

[AnxietyQAQ]

dsh-desktop-auth-issue.md

[Mydbyy]

补充几条能定位到代码的根因，以及一个已验证的规避方案。

环境：DSH Desktop 0.2.1-rc.5 / win-x64 / Electron 44.7.0 / Node 24.21.0 / Windows 11 26200。

为什么每次启动都会新增一个 cookie

• packages/client/connection/src/browser-auth.ts:79-84：requestAudience() 在 http 下返回 url.host，含端口：

  const url = new URL(`${secure ? 'https:' : 'http:'}//${host}`)
  return secure ? url.origin : url.host

• browser-auth.ts:117：cookie 名 = 前缀 + base64url(sha256(authority))，端口一变名字就变：

  return COOKIE_PREFIX + encodeBase64Url(createHash('sha256').update(authority).digest())

• browser-auth.ts:138：写入带 Max-Age 和 Expires，默认 cookieMaxAgeDays = 30；整个 browser-auth 路径里没有任何删除或覆盖旧 cookie 的逻辑：

  const attributes = `${name}=${value}; Max-Age=${String(maxAgeSeconds)}; Path=/; Expires=${new Date(expiresAt).toUTCString()}; HttpOnly; SameSite=Strict`

• apps/desktop-host/src/index.ts:36：Host 每次启动用随机端口，于是每次都签一个新的 cookie 名：

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

• 而 RFC 6265 里 cookie 不按端口隔离，所以 127.0.0.1 下所有历史端口的 dsh-auth-* 会被一并发送。

阈值能精确算出来

单条约 229 B（dsh-auth- + 43 字符 base64url + = + 值）。Node 默认 --max-http-header-size 是 16384 B，16384 / 229 ≈ 71.5。同一次 Host 进程里手工拼 Cookie 头实测：

cookie 数	Cookie 头	结果
1	226 B	200
70	16,027 B	200
71	16,256 B	431

临界点和公式严丝合缝，所以「用了一个月突然崩」是必然，不是偶发。

补充一个观察：welcome-backend.ts 用的是 Electron session fetch（net.fetch，注释写着 "Electron session fetch, retaining the Web authentication cookie"），走默认 cookie jar；而同仓库 apps/desktop/src/web-document.ts:43-49 的 authenticateWebHost() 是直接读 set-cookie 自己拼 Cookie 头，forwardWebRequest() 里用 headers.set('cookie', cookie) 显式带上，完全不依赖 jar。也就是说主窗口那条通路没有这个隐患，只有 welcome 这条走 jar。

建议的修复（任意一条都能止血，前两条互不冲突）

1. 启动时清理本 origin 下的历史 cookie：从 session.defaultSession.cookies.get({ domain: '127.0.0.1' }) 里筛出 dsh-auth- 前缀、且不属于本次端口的项，cookies.remove() 掉。
2. welcome 请求不要走 jar：把 authenticateWebHost() 拿到的 cookie 头直接交给 connectDesktopWelcome，和 forwardWebRequest 共用一套机制。
3. 把 cookieMaxAgeDays 默认值调小——这个 cookie 的寿命本来就不该超过进程，端口换了它就废了。
4. if (!authenticated.ok) 时把状态码带进异常，例如 Web authentication failed (HTTP 431)，至少可诊断。

用户侧规避（已实测，升级不丢）

在用户 patch 层 ~/.dsh/profiles/desktop/cordis.patch.yml 追加：

- id: connection
  name: "@deepseek-ai/dsh-client-connection"
  config:
    cookieMaxAgeDays: 3
    trustedHosts: !!js ctx.webStartup.trustedHosts

注意 patch 对 config 是整体替换而不是深合并，所以 trustedHosts 必须跟着写全。

实测（直接读 %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies）：

• 打补丁后新签发的 cookie，过期时间 = 启动时刻 + 3 天。20:51:04 那次启动对应 2026-11-03 12:51:07 UTC，秒级对得上；
• browser-auth.ts:380 的校验是 payload.expiresAt - payload.issuedAt > this.maxAgeMilliseconds 即判无效，所以调小 TTL 会让历史 30 天 cookie 立即失效（无害，每次启动自动重签）；
• 稳定态从「71 条 / 一个月」降到「约 15 条 / 3 天」，头体积 3.4 KB 左右，离 16384 很远。

[drscrewdriver]

pnpm install dsh-cookie-cleaner

① 先看现状（客户端开着也能跑，只会告诉你读不到）

& "$env:USERPROFILE.dsh\profiles\desktop\node_modules.bin\dsh-cookie-cleaner.cmd"

② 完全退出客户端：托盘图标 → 退出，并确认进程列表已无 DeepSeek Harness

Get-Process | Where-Object { $_.ProcessName -match 'DeepSeek|dsh' } # 应当没有输出

③ 清理（先看会删几条，再真删）

& "$env:USERPROFILE.dsh\profiles\desktop\node_modules.bin\dsh-cookie-cleaner.cmd" --clean --dry-run
& "$env:USERPROFILE.dsh\profiles\desktop\node_modules.bin\dsh-cookie-cleaner.cmd" --clean