[Bug][Windows][Desktop 0.2.2-rc.1] 启动必崩：dsh-auth-* cookie 随 --port 0 无限累积，撑爆请求头后自家 web server 返回 431

[arcqiufeng]

说明一下，这个是DeepSeek自己分析出来的bug。我启动不了，然后问他，他帮我修复好了。修复过程如下

[Bug][Windows][Desktop 0.2.2-rc.1] 启动必崩：dsh-auth-* cookie 随 --port 0 无限累积，撑爆请求头后自家 web server 返回 431

建议分类：General（本仓库 Issues 已关闭，故走 Discussions）
适用于：Desktop 0.2.2-rc.1（Electron 44.7.0 / Node 24.21.0 / Windows 11 x64）
已核对：桌面包内 @deepseek-ai/dsh 0.2.2-rc.1 与全局 @deepseek-ai/dsh 0.2.1-rc.2 两端同样存在

---

现象

桌面端完全无法启动，弹出内置致命错误对话框：

DeepSeek Harness 无法使用
应用无法启动或已意外停止。
desktop welcome: Web authentication failed
诊断报告: ...\crash-<time>-host.log

崩溃日志（%APPDATA%\@deepseek-ai\dsh-desktop\logs\crash-*-host.log）固定指向同一行：

Error: desktop welcome: Web authentication failed
    at connectDesktopWelcome (...\app.asar\lib\main.js:16856:31)
    at async Object.start (...\app.asar\lib\main.js:20386:22)

关键点：这不是文件损坏，也不是插件问题。“禁用第三方插件、备份 profile patch 并重启”这个安全模式按钮对它完全无效，重装应用也无效（数据在独立目录）。删掉 cookie 后立即可启动。

---

根因

四个环节叠加，形成一个必然触发的定时炸弹：

① 每次启动都用随机端口

@deepseek-ai/dsh-desktop-host/lib/index.js，Host 拉起 Web 应用时写死 --port 0：

const application = runProfile({
  environment: loadLayeredEnv("dsh"),
  profile: "desktop",
  resolvedProfile: { profile, installAnchor },
  patchFiles: [],
  args: ["--no-open", "--host", "127.0.0.1", "--port", "0"],   // ← 随机端口
  ...
});

② cookie 名由 authority（含端口）做哈希

@deepseek-ai/dsh-client-connection/lib/index.js：

const COOKIE_PREFIX = "dsh-auth-";
function cookieName(authority) {
  return COOKIE_PREFIX + encodeBase64Url(createHash("sha256").update(authority).digest());
}

cookieMaxAgeDays 默认 30，写入 Max-Age + Expires，是持久 cookie。

于是 端口一变 → cookie 名就变 → 新 cookie 永远覆盖不掉旧的，只会不断追加。

③ Chromium 的 cookie 作用域不含端口（RFC 6265）

cookie 装在 host_key = 127.0.0.1。发往任意 127.0.0.1:<port> 的请求都会带上全部同 host 的 cookie，不管它们的 authority 是哪个端口。

④ 全程没有任何清理

桌面壳里的 clearStorageData() 只作用于 Platform 登录窗口的独立分区会话（lib/main.js 的 cleanStorage / dispose），从不作用于主会话的 dsh-auth-*。

⑤ 服务端不放宽

@deepseek-ai/dsh-host-webserver/lib/index.js 里是裸的：

this.server = createServer(listener);   // 未传 maxHeaderSize，用 Node 默认 16 KiB

崩溃链

启动握手的 GET /?token=<launchToken> 由 net.fetch（Chromium）发出 → 带上全部累积 cookie → 请求头超 16384 字节 → DSH 自己的 web server 回 431 Request Header Fields Too Large → authenticated.ok === false → 抛 desktop welcome: Web authentication failed → 致命恢复对话框。

---

实测证据（Chromium netlog，--log-net-log 抓取）

对启动 URL 的同一个请求：

HTTP_TRANSACTION_SEND_REQUEST_HEADERS
  line: "GET /?token=... HTTP/1.1"
  Host: 127.0.0.1:59911
  Cookie: dsh-auth-XXXX=...; dsh-auth-YYYY=...; ...   ← 16194 字节，71 条

HTTP_TRANSACTION_READ_RESPONSE_HEADERS
  headers: ["HTTP/1.1 431 Request Header Fields Too Large", "Connection: close"]

量化：

指标	数值
累积的 dsh-auth-* cookie 条数	71
Cookie 请求头长度	16194 字节
整个请求头（含请求行与非 cookie 头 367 字节）	16561 字节
Node http 默认 --max-http-header-size	16384 字节
超出量	+177 字节

把 Cookie 头逐条 base64 解码后，71 条分属 71 个互不相同的 authority：

127.0.0.1:57005 / :62229 / :57815 / :50381 / :52273 / :62983 / :54338 / ...
本次请求 authority = 127.0.0.1:59911
真正匹配本次 authority 的 cookie 数 = 0

也就是说：这 16 KB 全是无效垃圾，一条都不匹配当前请求，纯粹把请求撑爆。

为什么 Node fetch 那一跳能过、Chromium 这一跳过不去

lib/main.js 里连续两跳：

hostCookie = await authenticateWebHost(ready.url);   // ① Node 原生 fetch：无 cookie jar，不发 Cookie 头
                                                     //    → 正常拿到 303 + Set-Cookie → 通过
welcomeBackend = await connectDesktopWelcome(ready.url, (input, init) => net.fetch(input, init), ...);
                                                     // ② Chromium net.fetch：带上全部 71 条 cookie
                                                     //    → 431 → !authenticated.ok → 抛错

第 ① 步成功、第 ② 步失败，正好证明问题出在 Chromium 一侧累积的 cookie，而非服务不可达、token 失效或 profile 损坏。

---

触发条件与影响面（重要：这不是个别现象）

每条 cookie 在请求头里约占 228 字节，可用配额约 16017 字节 → 上限约 70 条。

cookie 生命周期 30 天，所以稳态条数 ≈ 最近 30 天的启动次数。

只要平均每天启动超过约 2.3 次，30 天内必然突破 70 条，桌面端必然彻底无法启动。

实测本机：23 天内累积 71 条（约 3.1 次/天）后崩溃。按此速率，清理一次只能撑约 3 周，然后原样复发。

对于高频使用者，这等于“装好能用一阵，然后某天突然再也打不开”，而且安全模式、重装、换 profile 全都无效——用户基本无从自查。

---

建议修复（按优先级）

方案 A（最干净）：让 cookie 名与端口解耦

cookie 名固定为 dsh-auth，把 authority 放进已签名的 payload 里校验。同名 + 同 domain + 同 path 会互相覆盖，任何时刻最多存在 1 条 cookie，累积问题从根上消失。隔离性不受影响，因为 authority 已在 HMAC 签名覆盖范围内。

方案 B（最小改动）：启动时清理旧的同前缀 cookie

在 Desktop 壳拿到 ready.url 之后、connectDesktopWelcome 之前，用 session.defaultSession.cookies.remove() 删掉该 host 下全部 dsh-auth-*（或仅删除 authority 与当前不同的那些）。同样能保证最多 1 条。

方案 C（服务端兜底）

给 dsh-host-webserver 的 createServer 传入更大的 maxHeaderSize（如 64 KiB）。这只是掩盖症状，cookie 仍会无限增长，不建议单独使用，但可以和 A/B 一起作为纵深防御。

方案 D（辅助）：固定端口

避免 --port 0，或者至少保证同一用户复用同一端口。注意这会重新引入“端口被占用”类问题，需配合端口探测。

---

临时自救（给其他遇到同样问题的用户）

完全退出桌面端，删除 cookie 库里的 dsh-auth-* 记录（或直接删掉 %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies），再启动即可。

实测：71 条全删后立即恢复正常启动，不影响任何登录状态或会话数据（每条 cookie 都是每次启动重新签发的）。

---

环境

app:      @deepseek-ai/dsh-desktop 0.2.2-rc.1
electron: 44.7.0
node:     24.21.0
platform: win32 x64 (Windows 11, zh-CN)
bundled:  @deepseek-ai/dsh 0.2.2-rc.1
also affected: 全局 @deepseek-ai/dsh 0.2.1-rc.2（同一份 dsh-host-webserver 代码）

---

---

English summary

Title: Desktop 0.2.2-rc.1 fails to start after ~70 launches: dsh-auth-* cookies accumulate because the host port is random on every launch, until the Cookie header exceeds Node's 16 KiB limit and DSH's own web server answers 431.

Chain:

1. dsh-desktop-host starts the web app with --port 0 → a new random port each launch.
2. dsh-client-connection derives the session cookie name from sha256(authority), and authority includes the port (30-day persistent cookie).
3. Chromium scopes cookies by host only, never by port (RFC 6265), so every request to 127.0.0.1:<any> carries all accumulated dsh-auth-* cookies.
4. Nothing ever prunes them; the shell's clearStorageData() only touches the Platform login partition.
5. dsh-host-webserver calls bare createServer(listener) → Node's default 16384-byte header limit.
6. The launch GET /?token=... is sent via net.fetch; headers reach 16561 bytes (Cookie alone 16194 bytes / 71 cookies) → 431 → !authenticated.ok → desktop welcome: Web authentication failed → fatal recovery dialog.

Measured: 71 cookies, 71 distinct authorities, 0 matching the actual request authority. Node-side authenticateWebHost passes because Node's fetch has no cookie jar; Chromium's net.fetch fails — proving the cause is cookie accumulation, not profile corruption or an unreachable server.

Impact: At ~228 bytes per cookie and ~16017 bytes of budget, the limit is ~70 cookies; with 30-day expiry the steady state equals launches in the last 30 days. Anyone launching the desktop app more than ~2.3 times per day breaks it within 30 days. Safe mode, reinstall and profile resets all fail to help; only deleting the cookies recovers, and it recurs ~3 weeks later.

Suggested fix: Make the cookie name fixed (dsh-auth) and keep the authority inside the signed payload — same name/domain/path overwrites, so at most one cookie exists (isolation is preserved by the HMAC signature). Alternatively prune dsh-auth-* for the host right after ready.url; optionally raise maxHeaderSize as defense in depth.

[renleidedadi]

哈哈！我也遇到同样的问题了，当时我还在用0.2.1-rc.5还以为是旧版才有的问题，结果过来github一看：原来更新到0.2.2-rc.1也会发生这样的问题，然后又在Discussions搜索了一下：发现一大堆用户都来反馈431问题，看来cookie积累到这个时间节点已经达到到“撑爆期”了，接下来就要看看后续的更新会不会修复这个问题了

[longjiakai]

哈哈，怎么最近都是这个问题