DSH 桌面端 Cookie 溢出启动失败

[BurgerLei]

一、渠道核实（2026-11-06 实测）

渠道 | 状态 | 依据 -- | -- | -- GitHub Issues | ❌ 新帖关闭 | .github/ISSUE_TEMPLATE/config.yml: blank_issues_enabled: false；仓库 Issues 页 Open 0 / Closed 0 GitHub Discussions → Q&A | ✅ 官方指定 | CONTRIBUTING.md：「Identify and report issues or bugs in GitHub Discussions」 站内 /feedback <文本> | ⚠️ 次要 | 包 @deepseek-ai/dsh-command-feedback 存在该命令，但只写会话日志事件（"log-only"），不是缺陷工单 外部 PR | ❌ 不接受 | CONTRIBUTING.md：「we cannot accept external pull requests at the moment」

⇒ 反馈重点不是"请修"，而是「请把 5868dbc / 93bef27 cherry-pick 进 release 分支并重发 rc」。

---

三、中文正文（直接粘贴）

标题

代码块

[Desktop] Windows 启动失败：dsh-auth-* Cookie 累积导致请求头超 16 KB（0.2.2-rc.1 发行包仍含旧代码，master 已修）

正文

代码块

## 环境
- DSH Desktop 0.2.2-rc.1（Windows 11，安装版，nightly 通道）
- 桌面包内 dshBuildCommit：c59d10aff167ad7eefead4b3a9082fb57c8fbfe8
- 相关组件：@deepseek-ai/dsh-desktop、@deepseek-ai/dsh-client-connection、@deepseek-ai/dsh-desktop-host
现象
连续启动约 70 次后，桌面端在欢迎页阶段启动失败，日志：
Error: desktop welcome: Web authentication failed
    at connectDesktopWelcome (lib/main.js:16856)

此后每次启动都在同一处失败；把 %APPDATA%@deepseek-ai\dsh-desktop\Network\Cookies 移走（清空默认会话 Cookie）后可恢复，约 70 次启动后复发。
原因链

每次启动 Host 都用 --port 0 端口（dsh-desktop-host 的 runProfile），authority 为 127.0.0.1:<随机端口>。
dsh-client-connection 的 cookieName() = "dsh-auth-" + base64url(sha256(authority))，Max-Age 默认 30 天、Path=/，从不清理 ⇒ 每启动一次就多一枚 Cookie。
HTTP Cookie 不区分端口（RFC 6265），所有 dsh-auth-* 都带 host_key=127.0.0.1，于是每次请求全部上送。
桌面端欢迎流程的首个请求是 net.fetch(authenticatedUrl, { credentials: "include" })，Chromium 把全部 Cookie 拼进 Cookie: 头。
实测 71 枚 × 约 228 B ≈ 16,188 B，超过 Node 默认 maxHeaderSize 16,384 B，Host 拒收 ⇒ authenticated.ok === false ⇒ 抛错。

同一处的 Cookie 拼接还被账号 WebSocket（desktopAccountBackend）复用，所以账号连接也会受影响。
复现
全新安装后反复启动桌面端（每次 Host 端口不同），约 70 次后必然失败；或手工在默认会话里预置 70 枚 dsh-auth-* Cookie 后启动。
与我看到的上游修复的关系
master 上已有 5868dbc357（welcome/account 改用显式 Cookie 头，不再使用 cookie jar）与 93bef27ec7（启动时 removeLegacyHostCookies() 清理历史 Cookie），提交信息里也写明了 "after about 70" 这一阈值。
但 dsh-v0.2.2-rc.1 的 apps/desktop/src/main.ts:536 仍是旧写法，/compare/93bef27ec7...dsh-v0.2.2-rc.1 返回 behind_by=2 ⇒ 该发行包含的桌面包没有这两个修复。
期望

把上述两个提交 cherry-pick 到 release 分支并重发桌面包（优先）。
若短期无法重发，最小缓解：欢迎流程只发送当前 authority 对应的那一枚 Cookie，并在启动时清理其它 dsh-auth-*。
失败日志建议带上状态码、Cookie 数量与 Cookie 头字节数，便于下次自证。

---

四、English version（可直接替换正文）

Title

代码块

[Desktop] Windows startup fails: accumulated dsh-auth-* cookies overflow the 16 KB request header (0.2.2-rc.1 still ships pre-fix code; master already fixed)

Body

代码块

## Environment


DSH Desktop 0.2.2-rc.1 on Windows 11 (installed build, nightly channel)
Bundled dshBuildCommit: c59d10aff167ad7eefead4b3a9082fb57c8fbfe8
Components: @deepseek-ai/dsh-desktop, @deepseek-ai/dsh-client-connection, @deepseek-ai/dsh-desktop-host

Symptom
After roughly 70 desktop launches, startup fails at the welcome stage:
Error: desktop welcome: Web authentication failed
    at connectDesktopWelcome (lib/main.js:16856)

Every later launch fails identically. Moving %APPDATA%@deepseek-ai\dsh-desktop\Network\Cookies aside (i.e. clearing the default session cookie store) restores startup; it recurs after another ~70 launches.
Mechanism

Each launch starts the Host with --port 0 (dsh-desktop-host runProfile), so the authority is 127.0.0.1:<random port>.
dsh-client-connection mints cookieName(authority) = "dsh-auth-" + base64url(sha256(authority)) with the default 30-day Max-Age and Path=/, and never removes old ones — one new cookie per launch.
Cookies are not port-scoped (RFC 6265): all of them share host_key=127.0.0.1 and are sent on every request.
The welcome flow's first request is net.fetch(authenticatedUrl, { credentials: "include" }), so Chromium joins every cookie into one Cookie: header.
Measured: 71 cookies × ~228 B ≈ 16,188 B, above Node's default maxHeaderSize of 16,384 B. The Host rejects the request, authenticated.ok is false, and 16856 throws.

The same unfiltered join also feeds the account WebSocket (desktopAccountBackend), so that path is affected too.
Reproduction
Repeatedly launch the desktop app (fresh random Host port each time) on a clean install; it fails around the 70th launch. Alternatively pre-seed ~70 dsh-auth-* cookies in the default session and launch.
Relation to the fix already on master
master contains 5868dbc357 (welcome/account backends send an explicit Cookie header, no cookie jar) and 93bef27ec7 (removeLegacyHostCookies() at Host start); the former even mentions "after about 70".
However dsh-v0.2.2-rc.1's apps/desktop/src/main.ts:536 still has the old code, and /compare/93bef27ec7...dsh-v0.2.2-rc.1 reports behind_by=2 — the release tag does not contain either fix.
Request

Cherry-pick both commits into the release branch and republish the desktop build (preferred).
If a rebuild is not possible soon, a minimal mitigation: send only the cookie for the current authority, and purge other dsh-auth-* cookies at startup.
Log the status code, cookie count and Cookie-header byte size on failure so users can self-diagnose.

---

五、发帖前检查

•  已剔除本机隐私信息（用户名、完整盘符路径、备份文件哈希、插件清单）
•  未包含任何凭据、Cookie 值、日志原文路径
•  附可复算证据（提交号、/compare 结果、行号、字节数），便于官方核验
•  需你本人登录 GitHub 账号后提交（本机无 GitHub 凭据，且不代发公开内容）

---

六、备注：本机已另有临时修复

本机 app.asar 已打等长热补丁（_patch</code>，见 DSH-Cookie溢出修复说明.md），补丁行为与上游 93bef27ec7 思路一致：只发送当前 authority 的 Cookie + 清理历史 dsh-auth-*。 官方重发修复版后应卸载本机补丁：重装/升级会覆盖 app.asar，补丁自然失效；若届时仍有残留 Cookie，首次启动的清理逻辑会顺带清掉。

[xuan15124]

一样的问题 Mac也遇到了
cookie 堆积