Desktop startup crash loop: accumulated dsh-auth-* cookies exceed the Host's 16 KB header limit (HTTP 431)

[terryzwt]

Summary

The desktop app enters a startup crash loop after enough launches: the shell fails during desktop welcome: Web authentication and exits. Root cause is unbounded accumulation of dsh-auth-* session cookies in the Electron session jar, until the Cookie request header exceeds the Host's 16 KB HTTP header limit and every launch fails with HTTP 431.

（中文版摘要见文末。）

Environment

• App: @deepseek-ai/dsh-desktop 0.2.1-rc.3
• Platform: macOS arm64 (also affects any platform — the mechanism is generic)
• Electron: 44.7.0 / Node: 24.21.0

Root cause analysis

In @deepseek-ai/dsh-client-connection, the browser-session cookie name is derived from the authority including port:

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

The Desktop Host binds to a new random 127.0.0.1 port on every launch, so every launch mints a cookie with a different name (dsh-auth-<sha256("127.0.0.1:<port>")>). Cookies carry a 30-day expiry and are never cleaned up. Since cookies are not port-scoped, Chromium sends every accumulated dsh-auth-* cookie on each request to 127.0.0.1.

After ~70 launches the jar held 71 live cookies ≈ 16,117 bytes of Cookie header (measured). Adding the remaining request headers exceeds Node's default --max-http-header-size (16,384), so the Host responds 431 Request Header Fields Too Large.

The desktop shell then maps any non-OK response to a startup failure (connectDesktopWelcome throws on !authenticated.ok), and each failed attempt stores one more cookie via Set-Cookie on the 431 response, creating a death spiral (observed 7 crash-restart cycles in ~3 minutes):

Error: desktop welcome: Web authentication failed
    at connectDesktopWelcome (.../app.asar/lib/main.js:8886:31)
    at async Object.start (.../app.asar/lib/main.js:12195:22)

Reproduction

1. Install @deepseek-ai/dsh-desktop and launch it once per day for ~2–3 weeks (each launch = new random host port = one new cookie).
2. Observe ~/Library/Application Support/@deepseek-ai/dsh-desktop/Cookies accumulate one dsh-auth-* row per launch, all unexpired (30-day TTL).
3. Once the combined Cookie header for 127.0.0.1 exceeds 16 KB, every launch crashes with the log above (~/Library/Logs/DeepSeek Harness/crash-*-host.log).

Current behavior

Startup crash loop; the app never opens. Each retry adds another cookie, worsening the failure.

Expected behavior

Startup succeeds regardless of launch count.

Suggested fixes (any one)

1. Make the cookie name port-independent (e.g. hash the host only, not host:port), or give the Host a stable port per profile so the same cookie name is reused and refreshed in place; or
2. Have the desktop shell purge stale dsh-auth-* cookies from the session jar before authenticating (it already owns the jar), e.g. keep only the cookie matching the current authority; or
3. As a mitigation only: start the Host's HTTP server with a larger --max-http-header-size.

Workaround for affected users

Quit the app completely, then delete the accumulated cookies (macOS example):

sqlite3 "$HOME/Library/Application Support/@deepseek-ai/dsh-desktop/Cookies" \
  "DELETE FROM cookies WHERE name LIKE 'dsh-auth-%';"

Relaunch — it starts cleanly. No account login is lost; dsh-auth-* is only the local Host session cookie. The problem will slowly recur until one of the fixes above ships.

---

中文版摘要

桌面端每次启动时，Desktop Host 会在 127.0.0.1 的随机新端口上监听，而会话 Cookie 名是 dsh-auth-<端口哈希>，因此每次启动都会签发一个新名字的 Cookie（30 天有效、从不清理）。Cookie 不区分端口，约 70 次启动后 Chromium 会把全部 ~71 个 Cookie（约 16.1 KB）一起发给 127.0.0.1，超过 Node 默认 16 KB 的请求头上限，Host 返回 431，桌面端把它报成 desktop welcome: Web authentication failed 并崩溃退出；且每次失败还会再新增一个 Cookie，形成恶性循环。建议：Cookie 名不绑定端口（或 Host 使用固定端口），或启动时清理旧的 dsh-auth-* Cookie。临时 workaround：退出应用后删除上述数据库中的 dsh-auth-% Cookie 即可正常启动。

[Akihisx]

Independent confirmation on Windows, plus one correction.

Environment: Windows 11 x64, @deepseek-ai/dsh-desktop 0.2.1-rc.3 (Electron 44.7.0 / Node 24.21.0), jar at %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies.

Measured against a live Host (plain node:http requests carrying a synthetic Cookie header):

Cookie header	response
16,065 B	401
16,465 B	431

The 431 is produced by Node's HTTP header parser, not by DSH: the response carries only connection: close and no set-cookie.

Size math (from the minting code in packages/client/connection): name dsh-auth- + base64url(sha256) = 52 B, value v1.<136>.<43> = 173 B, plus = and ; → 228 B per cookie. 16,384 / 228 = 71.9, so the 72nd cookie cannot fit at all — before Host, User-Agent, Accept and the sec-fetch-* set are counted. With those, the practical threshold is ~66–70 launches, which matches both "~70" reports.

One correction to the crash-loop paragraph: a failed launch does not mint another cookie. The 431 is returned by the parser, so the request never reaches the Host and no Set-Cookie is emitted; the jar stops growing. The failure is therefore stably broken rather than a spiral, and it only clears when the oldest cookies expire (30-day Max-Age) — which is why it reads as permanent.

Still present on main: apps/desktop/src/main.ts in 0.2.2-alpha.2 (checked 2026-10-29) still runs hostCookie = await authenticateWebHost(ready.url) (line 531) then connectDesktopWelcome(ready.url, ...) (line 535) with no purge in between, so the jar keeps whatever history it has and the welcome request keeps carrying all of it.

#11366 carries a shell-side patch (remove dsh-auth-* cookies before authenticateWebHost) that was verified by its author against an already-broken profile — that, or making the cookie name host-scoped instead of host:port-scoped, looks like the smallest fix. Posting here so the two threads are tied together.

Local workaround we run with the app closed — prune the rows directly; node:sqlite is enough, no sqlite3 binary required:

const { DatabaseSync } = require('node:sqlite')
const db = new DatabaseSync(cookiesPath)
db.exec("delete from cookies where name like 'dsh-auth-%'")
db.close()

It is hooked into our restart script, so the jar never holds more than the current launch's cookie.

[rhkiswani]

One number that may help pick between the three fixes: Chromium's own jar cap is 180 cookies per domain (every host-only cookie on 127.0.0.1 lands in that one bucket), evicting least recently used. At the 228 B per cookie measured above, the cap is only reached at about 41 KB of Cookie header, so browser-side eviction never kicks in before Node's 16 KB parser limit. Raising --max-http-header-size to 32 KB (fix 3) just moves the wall to roughly 140 launches. Only a host-scoped cookie name, so each launch overwrites the previous cookie in place (fix 1), or the purge before authenticateWebHost (fix 2) actually bounds the jar.

(We use the same limits in the cookie jar for Mars, a browser we are building, which is why I had the number handy.)

[KannaKuron]

Independent confirmation on macOS arm64, with one platform-path detail.

Environment: @deepseek-ai/dsh-desktop 0.2.1-rc.3, Electron 44.7.0, Node 24.21.0, macOS arm64.

Measurements:

• Cookie jar: ~/Library/Application Support/@deepseek-ai/dsh-desktop/Cookies (SQLite; on macOS there is no Network/ subdirectory).
• 71 rows with host_key='127.0.0.1' AND name LIKE 'dsh-auth-%', each about 227 bytes.
• Chromium netlog for GET http://127.0.0.1:<port>/?token=... reports request headers "byte_count": 16635, followed by HTTP/1.1 431 Request Header Fields Too Large.
• connectDesktopWelcome() only checks response.ok, so the 431 is surfaced as desktop welcome: Web authentication failed.
• Deleting only those dsh-auth-* rows fixes the very next launch. Disabling third-party plugins, using recovery/safe mode, or disabling the system proxy made no difference.

macOS workaround (app fully quit first):

UD="$HOME/Library/Application Support/@deepseek-ai/dsh-desktop"
sqlite3 "$UD/Cookies" "DELETE FROM cookies WHERE host_key='127.0.0.1' AND name LIKE 'dsh-auth-%';"

Suggested fix: the minimal source change in #11408 (clear stale dsh-auth-* cookies before authenticateWebHost(ready.url)) matches what was verified here. Using a fixed cookie name per host and overwriting it each launch would also avoid unbounded growth.

One extra diagnostic suggestion: include the HTTP status in the error, e.g. Web authentication failed (HTTP 431), so this is not mistaken for an account/session problem.

[xx529]

Independent confirmation on macOS arm64, plus a client/server isolation check and a verified workaround.

Environment: @deepseek-ai/dsh-desktop 0.2.1-rc.3, Electron 44.7.0, Node 24.21.0, macOS arm64 (Darwin 25.6.0). Jar path on this platform: ~/Library/Application Support/@deepseek-ai/dsh-desktop/Cookies.

Measurements at 71 live dsh-auth-* cookies for 127.0.0.1:

• Cookie: header alone: 16,186 B
• Full header block with Chromium's usual request headers (UA / Accept / Accept-Encoding / sec-ch-ua…): 16,676 B → HTTP/1.1 431 Request Header Fields Too Large
• Same cookies, no launch token → 401 (the 431 is produced by the parser before auth runs)

The Host itself is fine. I started it standalone and hit the printed launch URL:

ELECTRON_RUN_AS_NODE=1 DSH_HOME=~/.dsh \
  "/Applications/DeepSeek Harness.app/Contents/MacOS/DeepSeek Harness" --expose-internals \
  ".../app.asar/dsh/node_modules/@deepseek-ai/dsh-desktop-host/lib/index.js" \
  ".../app.asar/dsh" ~/.dsh/profiles/desktop ".../runtime/primary-runtime"

curl against that URL returns 303 + Set-Cookie every time, with or without existing cookies. It only flips to 431 when the request carries all 71 accumulated cookies plus browser headers. Note authenticateWebHost() uses Node fetch (no cookie jar) and succeeds first, so the failure is specifically the cookie-bearing net.fetch(readyUrl, { credentials: "include" }) in connectDesktopWelcome — consistent with the analysis above.

Workaround verified — clearing the stale jar restores startup:

# quit the app first
cp ~/Library/Application\ Support/@deepseek-ai/dsh-desktop/Cookies{,.bak}
sqlite3 ~/Library/Application\ Support/@deepseek-ai/dsh-desktop/Cookies \
  "delete from cookies where host_key='127.0.0.1' and name like 'dsh-auth-%';"

After relaunch exactly one dsh-auth-* cookie is re-minted (jar stays at 1) and the app reaches the workspace with no crash report. Accumulation restarts at one cookie per launch, so this recurs after ~70 further launches; the 30-day expiry is far too long to clean up in time.