desktop: stale dsh-auth-* cookies overflow Node maxHeaderSize (16384) and break startup auth

[rg2304luyue]

Summary

Every desktop launch mints a new auth cookie for 127.0.0.1 whose name encodes the
random listen port, with a 30-day Max-Age. Old generations are never removed, so the
Electron cookie jar grows by one cookie per launch. Chromium replays all of them on the
welcome 303 -> / hop, and once the Cookie header passes Node's default
maxHeaderSize (16384 B) the Host answers 431, which the desktop reports as
desktop welcome: Web authentication failed (phase: startup).

The app becomes unusable after roughly 70 restarts and stays that way until the
cookie jar is manually cleaned.

Environment

• dsh desktop (Windows x64), channel nightly (resources/app-update.yml: provider generic,
  url https://download.deepseek.com/dsh-desk/feeds/win-x64/)
• Host runtime: Node 24.21.0 (no maxHeaderSize override in the host webserver options)
• Desktop core version: not exposed by the packaged app (app.asar); please add it to the
  crash report / About panel if triage needs it
• Repro host: Windows 11, cookie DB at %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies

Root cause chain

1. dsh-client-connection builds the cookie name as
   COOKIE_PREFIX ("dsh-auth-") + encodeBase64Url(sha256(authority)) where authority is
   127.0.0.1:<random port>; base64url(sha256) is a fixed 43 chars, so each name is 53 B.
   The cookie carries a 30-day Max-Age.
2. The port is random per launch -> the name changes on every launch, and the persistent
   cookie jar keeps every generation until it expires.
3. connectDesktopWelcome does net.fetch(ready.url) and follows the 303 to /; Chromium
   attaches every cookie for the origin.
4. Host HTTP server uses Node's default maxHeaderSize = 16384 B -> 431 ->
   authenticated.ok === false -> startup aborts.

Measurements (this machine, real cookies)

state	Cookie header	result
50 cookies	~11.4 KB	200
70 cookies	~15.9 KB	200
70 cookies + the 226 B cookie issued during the redirect	16,552 B	431
71 cookies (initial ?token= request)	16,552 B	431
71 cookies, no valid cookie sent	-	401 (so 431 is decided before auth)

sum(length(name)+length(value)+3) over host_key='127.0.0.1' reproduces the header size
within ~120 B. Chromium's ~180-cookies-per-domain cap is never reached: the 16 KB header
limit blows first, and the jar does not self-heal.

Accumulation on this machine: 71 cookies in 9.2 days = ~7.7 launches/day, i.e. the failure
point is reached after ~70 launches.

Suggested fixes (smallest first)

1. Make it a session cookie — drop Max-Age/Expires from the dsh-auth-* cookie.
   A new port already means a new token on the next launch, so persistence buys nothing and
   the jar empty itself when the app closes. One-line change, no migration.
2. Prune on startup — before issuing the cookie, delete all dsh-auth-* cookies for
   127.0.0.1 (session.defaultSession.cookies.remove, or cookies.flushStore() after a
   filtered cleanup). Also handles hosts already stuck at 71 cookies.
3. Stable name — use a constant name plus a rotating value (or __Host--style single
   cookie), so the jar holds one entry regardless of port.
4. Defensive — pass maxHeaderSize when creating the host HTTP server, or authenticate via
   a header/URL token instead of a cookie on the welcome hop.

Workaround users can run today

Close the app, then delete only this origin's stale cookies (SQLite
delete from cookies where host_key='127.0.0.1' and name like 'dsh-auth-%').
Better still: run the cleanup before launching, while the DB is not locked by Chromium.

Why it is worth fixing upstream

It is not a misconfiguration: any long-lived install on the nightly channel hits it in about
a week of normal restarting, and the failure mode (silent startup abort behind a generic
crash dialog) gives no hint about cookies.

[Smalldy]

Independent repro on Windows x64 (dsh-desktop 0.2.1-rc.3, Electron 44.7.0, Node 24.21.0): with 71 dsh-auth-* rows, net.fetch(launchUrl, {credentials:'include'}) in the Electron main process returns 431; after clearing the jar the same call returns 200.

One additional stopgap verified without patching app.asar: set

NODE_OPTIONS=--max-http-header-size=131072

in the user environment. The desktop host runs as an Electron Node-mode child and inherits it (the packaged main process only logs the usual "Most NODE_OPTIONs are not supported" warning). With the override, the same host returns 303 for a 30 KB Cookie header instead of 431. Since Chromium caps cookies per domain at ~180 (~36 KB here), this prevents the startup failure in practice, but it is only a mitigation — the prune/session-cookie fix is still needed. Users who don't want a global Node option can instead delete dsh-auth-% rows from Network/Cookies with the app closed.

[Rainy99]

Great👍

[SuperAllenYao]

macOS arm64 confirmation, exact measurements, and code anchors

Same failure on macOS, so this is not Windows-specific — adding the missing platform plus hard numbers from a real broken install.

Environment

• macOS 27.0.1 (arm64)
• @deepseek-ai/dsh-desktop 0.2.1-rc.5, Electron 44.7.0, Node 24.21.0, channel nightly
• Cookie store: ~/Library/Application Support/@deepseek-ai/dsh-desktop/Cookies (note: macOS keeps it at the profile root, not under Network/)
• Crash report: ~/Library/Logs/DeepSeek Harness/crash-<ts>-host.log →
  Error: desktop welcome: Web authentication failed at connectDesktopWelcome (.../app.asar/lib/main.js:8886:31)

State when it stopped starting

• 71 rows, all host_key = 127.0.0.1, all named dsh-auth-<43-char base64url>
• sum(length(name) + 1 + length(value) + 2) = 16,188 B of name=value pairs; every value is 173 B, path=/, HttpOnly, persistent, 30-day expiry
• first row was created at the very first launch (2026-10-17 17:37 local), roughly 5 launches/day, 71 rows in 13 days

431 boundary reproduced against a live Host

• synthetic Cookie header of 16,000 B → 401 (request parsed, normal auth rejection)
• 16,500 B → 431 Request Header Fields Too Large
• So the 16,188 B of cookies plus Host / User-Agent / Accept is already past Node's default maxHeaderSize = 16384.

The cookie name is authority-derived (verified, not inferred)

sha256("127.0.0.1:58548") → dsh-auth-SAzlosSaWmMs1Zs8ZVfMgSOqFenwmbypmR_BGL0qyZI, which matches the newest DB row byte-for-byte. Since the Host port is ephemeral, every launch mints a new name, and Chromium keeps every generation.

Code anchors in the packaged 0.2.1-rc.5 build

• dsh/node_modules/@deepseek-ai/dsh-desktop-host/lib/index.js:238 — spawns the Host with ["--no-open", "--host", "127.0.0.1", "--port", "0"]
• dsh/node_modules/@deepseek-ai/dsh-client-connection/lib/index.js:336 — COOKIE_PREFIX + encodeBase64Url(sha256(authority))
• lib/main.js:12196 — net.fetch(ready.url, { credentials: "include" }), with the welcome handler joining every jar cookie into one Cookie header
• lib/main.js:8887 — if (!authenticated.ok) throw new Error("desktop welcome: Web authentication failed"), which is why 431 surfaces as an authentication failure

Not caused by third-party plugins. The first cookie was written at first launch, 9 days before any plugin was installed on this machine, and disabling plugins leaves the failure unchanged.

Suggested upstream fixes (any one is sufficient)

1. Before connectDesktopWelcome, drop jar cookies whose name does not belong to ready.url's authority.
2. Send the first welcome request with credentials: "omit" and apply the 303 Set-Cookie manually, the way authenticateWebHost already does.
3. Run the loopback Host in a non-persistent session partition so its cookies die with the process.
4. Have the Host expire sibling dsh-auth-* cookies in its authenticated response (Set-Cookie: <old>=; Max-Age=0).
5. At minimum, map 431 to a distinct error so the recovery dialog reports "request header too large" instead of "authentication failed" — the current message sends users down the wrong path.

Local stopgap without patching app.asar: a small Host plugin that prunes stale dsh-auth-* rows on every boot, keeping the jar at two rows (~480 B). Happy to test a build that implements any of 1–4.

[XingleCanyue]

Windows 11 x64 + @deepseek-ai/dsh-desktop 0.2.1-rc.5 / Electron 44.7.0 / Node 24.21.0 复现，数据与上面一致，另外补充一个二次损坏的现象。

我这台的状态

• %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies 中 71 条 host_key='127.0.0.1' 的
  dsh-auth-*，每条 value 173 B，30 天有效期，最早一条来自 10 月 8 日（约 7 次启动/天）。
• 按 sum(length(name)+length(value)+4) 估算 Cookie 头 ≈ 16,259 B，叠加常规请求头后
  超过 Node 默认 maxHeaderSize = 16384，宿主返回 431；
  lib/main.js:8887 把非 2xx 一律报成
  Error: desktop welcome: Web authentication failed（phase: startup）。
• 清空 71 条后立即恢复，下一次启动自动签发新的，说明凭据本身没坏。

比启动失败更严重的二次损坏
失败对话框给出的建议是「禁用第三方插件，备份 profile patch，然后重启」。这条建议有两个问题：

1. 认证失败发生在插件加载之前，禁用插件对故障没有任何作用，只会让人误判方向；
2. 该流程会把 $DSH_HOME/profiles/desktop/cordis.patch.yml（我的有 11 个配置项，
   约 32 KB）直接替换成空数组 []。我照做之后，所有自定义 provider、模型参数、
   apiKeyEnv 绑定全部丢失——启动失败了，还把用户的配置一起清掉了。

建议在修复 cookie 累积的同时，把这个恢复流程改掉：

• 认证类错误不要建议动插件配置；
• 任何「备份」动作真的只备份（copy），不要以清空为默认行为；
• 至少把 431 映射成独立错误码，让提示说「请求头过大」而不是「认证失败」。

另外上面 @Smalldy 给的 NODE_OPTIONS=--max-http-header-size=131072 在我这台也有效，
可作为未修复前的临时缓解。

[paleech0]

独立复现（Windows 11 x64，DSH Desktop 0.2.1-rc.5 / Electron 44.7.0 / Node 24.21.0），补充临界值的精确数据：

• 第 70 条 dsh-auth-* 时：Cookie 头 sum(len(name)+len(value)+3) = 15,958 B，请求能正常解析（返回 401 = 认证层拒绝）；
• 第 71 条时：约 16,486 B，Host 在解析层直接返回 431（Node maxHeaderSize 默认 16384），早于认证；
• 连续 7 条 crash-*-host.log 全部是 Error: desktop welcome: Web authentication failed（phase: startup，connectDesktopWelcome，main.js:8886），与主楼分析一致；
• 本机约 2.4 次启动/天，30 天有效期窗口内正好达到 71 条——说明即使"不算高频"的用户也会在约一个月内触发。

临时缓解已验证有效：完全退出桌面端后，删除 Network/Cookies 中 host_key IN ('127.0.0.1','localhost','::1') AND name LIKE 'dsh-auth-%' 的行即可恢复；NODE_OPTIONS=--max-http-header-size=131072 在本机同样有效。

另外同意主楼第 5 条建议：431 被统一映射成 "authentication failed" 会误导排查方向（本机一开始先怀疑了第三方插件和代理，实际上都无关）。修复前，建议至少在恢复对话框里提示"Cookie 请求头过大，清除 dsh-auth-* 后重试"。

（本复现由用户授权 DSH 助手整理提交。）

[XiaoYanvc]

Confirmed independently on Windows 11 x64 — DSH Desktop 0.2.1-rc.3 (dshBuildCommit be72761e), Electron 44.7.0, Node 24.21.0, stock install, no third-party plugins. Measurements match this thread within a few bytes:

• one dsh-auth-* cookie: name 53 B + value 173 B = 226 B
• 70 cookies → Cookie: ≈ 15.9 KB → 401 (request parsed, normal auth rejection)
• 72 cookies → ≈ 16.4 KB → 431, surfaced as desktop welcome: Web authentication failed

Recovery: fully quit the desktop app, delete only dsh-auth-% rows for loopback hosts while the app is closed, relaunch. A fresh cookie is then issued and startup works again — so it is purely jar growth, not a broken credential.

Since hand-editing sqlite rows is not user-friendly, we packaged a small Windows PowerShell tool (attached dsh-cookie-tool.zip, PS 5.1+, no admin required):

• dsh-cookie-tool.cmd — menu: status (read-only count of dsh-auth-*), one-click repair, install/uninstall guard task
• dsh-cookie-fix.ps1 — backs up Network/Cookies to _cookie_backups, then deletes only the dsh-auth-* rows (falls back to deleting the jar if no sqlite client is available); -DryRun verified, other cookies and login state are preserved
• dsh-launch-and-clean.cmd — launch wrapper that prunes stale cookies before starting DSH
• optional hourly Scheduled Task "DSH Cookie Guard", runs only when DSH is closed

Upstream, I agree with the main thread: prune dsh-auth-* cookies for the current 127.0.0.1 origin at startup (also fixes already-broken installs), or drop Max-Age so the jar empties on exit, or use a stable cookie name. And please map 431 to a distinct "request header too large" error — the current generic auth failure (plus the "disable plugins" recovery advice reported by @XingleCanyue) sends users down the wrong path. Searching dsh-auth returns dozens of duplicate reports, so a fix + clearer error message would collapse a lot of the triage/support load.

---

中文补充（同一台机器，独立复现）：

• 单条 dsh-auth-* 226 B；70 条约 15.9 KB → 401；72 条约 16.4 KB → 431（表现为 Web authentication failed）。
• 恢复方式：完全退出 DSH，删除 host_key='127.0.0.1' AND name LIKE 'dsh-auth-%' 的行，重启即恢复；凭据本身没坏，只是 cookie 库无界增长。
• 为方便普通用户，附上 Windows 一键修复/防复发工具 dsh-cookie-tool.zip：状态检查、备份后精准删除 dsh-auth-*（保留其他 cookie 与登录态）、启动前自动清理、可选的每小时计划任务，-DryRun 已验证。
• 建议上游启动时清理历史 cookie（顺带修复已损坏的安装），或取消 30 天持久化 / 改用稳定 cookie 名；并把 431 映射成独立的「请求头过大」提示。

dsh-cookie-tool.zip