Desktop startup dies after ~70 launches: stale dsh-auth-* cookies overflow Node's 16KB header limit (HTTP 431)

[eeljoe]

Bug: desktop crashes at startup once stale dsh-auth-* cookies exceed Node's 16 KB header limit

Environment: @deepseek-ai/dsh-desktop 0.2.2-rc.1, win32 x64, Electron 44.7.0 / Node 24.21.0

Symptom

The desktop shell dies during startup with:

Error: desktop welcome: Web authentication failed
    at connectDesktopWelcome (app.asar/lib/main.js:16861)

The host process is healthy — it emits the ready URL and serves RPCs — but the shell's net.fetch(ready.url, { credentials: "include" }) receives a non-2xx response and the app exits.

Root cause

The host replies HTTP 431 Request Header Fields Too Large. I captured the real response by patching a probe into connectDesktopWelcome locally:

{ "targetUrl": "http://127.0.0.1:53376/?token=…", "status": 431,
  "statusText": "Request Header Fields Too Large",
  "finalUrl": "", "redirected": false,
  "headers": [["connection","close"]], "body": "" }

The request never reaches routing — Node's HTTP server rejects it at parse time because the Cookie header alone is ~16.1 KB and Chromium's default headers push the total over the 16 KB maxHeaderSize limit.

The cookie jar contained 71 stale dsh-auth-* cookies on 127.0.0.1. The accumulation is structural, per packages/client/connection/src/browser-auth.ts:

• requestAudience() returns url.host for HTTP — including the ephemeral port (L79)
• cookieName(authority) = dsh-auth- + base64url(sha256(authority)) (L116) — so every launch on a new port mints a new cookie name; nothing is ever overwritten
• sessionCookie() writes a persistent cookie: Max-Age, Expires (default 30 days via cookieMaxAgeDays, src/index.ts), Path=/, HttpOnly, SameSite=Strict (L138)
• Cookies are host-scoped, not port-scoped — the browser sends all dead dsh-auth-* cookies to every instance on 127.0.0.1, and verifyBrowserCookie only reads the one matching the current authority
• There is no cleanup path (no logout, no eviction)

So: +1 permanent ~226 B cookie per launch → header grows monotonically → after ~70 launches the shell's fetch crosses 16 KB → 431 → fatal. The desktop is effectively bricked until the cookie store is manually cleared. dsh web / CLI hosts are unaffected because a real browser profile doesn't accumulate the same jar (and/or the CLI reuses ports).

Reproduction

1. Launch desktop (or dsh web pointed at a persistent browser profile) ~70 times, or simply pre-seed ≥70 dsh-auth-* cookies for 127.0.0.1.
2. Start the app → net.fetch fails with 431 → desktop welcome: Web authentication failed → exit.

Verified by deleting all dsh-auth-* rows from %APPDATA%/@deepseek-ai/dsh-desktop/Network/Cookies: the app then boots normally and host rpc ok calls flow.

Notes

The port binding is intentional (.agents/notes/…/2026-08-24-browser-token-authentication.md: independent Web ports must not collide). But the side effect — unbounded, never-cleaned accumulation in a host-scoped jar — isn't covered by the design.

Possible fixes without breaking multi-port coexistence:

• Self-cleaning at mint time: in authorizeIndex, scan the incoming Cookie header for dsh-auth-* names that don't match the current authority and emit Set-Cookie: <name>=; Max-Age=0 alongside the fresh cookie. Server-side only, no client change needed, and stale entries die on the next launch instead of at day 30.
• Desktop-side sweep: at startup, the Electron shell could delete dsh-auth-* cookies whose authority doesn't match the current host:port before calling connectDesktopWelcome.
• Alternatively make the minted cookie session-scoped for the desktop launcher path (the launch-token exchange is already per-process), keeping the 30-day cookie only for real browser sessions.

Happy to provide the captured response JSON and the cookie DB dump if useful.

[eeljoe]

Duplicate of #9924 (same root cause, independently reproduced on 0.2.2-rc.1/Windows: 71 stale cookies, 431 captured). Closing — additional evidence and a 5th fix option posted on the canonical thread.