Desktop shell hard-fails on startup after enough launches: stale dsh-auth-* cookies overflow Node's header limit (431), surfaced as "Web authentication failed"

[Illusory-moon]

Environment

• Windows 11 (build 26300, x64)
• @deepseek-ai/dsh-desktop 0.2.1-rc.2 (Electron 44.7.0, bundled Node 24.21.0)
• No custom connection config (cookieMaxAgeDays left at its default of 30 days)
• Installed 2026-10-17 and working normally for days; the failure appeared with no upgrade, no reinstall and no profile edit in between

Symptom

Every cold start fails at startup and the window shows "DeepSeek Harness is unavailable". The crash report records:

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)

This is deterministic: 9 consecutive launches failed the same way, each with a different shell pid. Closing and relaunching, or clearing the window state, changed nothing.

Reproduction

1. Launch the desktop app repeatedly (each launch listens on a random port, which is the important part).
2. After roughly 60–75 launches, every subsequent launch fails with the error above.
3. dsh web in a browser accumulates the same cookies for 127.0.0.1 and will hit the same wall after the same number of runs.

Evidence

Chromium NetLog (--log-net-log, capture mode Everything) from a failing launch shows the index request being rejected before it reaches the application:

request: GET /?token=<redacted> HTTP/1.1   (Host: 127.0.0.1:<port>)
Cookie:  dsh-auth-<hash>... ; ...          (71 cookies, ~15.5 KB total)
response: HTTP/1.1 431 Request Header Fields Too Large

The cookie table in the desktop profile (%APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies) held exactly 71 rows, all name LIKE 'dsh-auth-%', all for host_key = 127.0.0.1, none for any other origin.

The host itself is healthy, which rules out profile or plugin breakage. I booted the bundled dsh-desktop-host directly and probed it:

• GET /?token=... → 303 + Set-Cookie
• GET / with that cookie → 200
• GET / without it → 401

So authentication succeeds; only the oversized request is refused, and the Electron shell reports it as an auth failure because connectDesktopWelcome checks response.ok and the 431 is all it sees.

Root cause

The auth cookie name is dsh-auth- + a hash of the normalized hostname and port (see the Connection docs: cookies "bind the normalized hostname plus port in both their deterministic name and signed payload"), and it carries Path=/, HttpOnly, SameSite=Strict, with an absolute lifetime of cookieMaxAgeDays (default 30).

HTTP cookies are port-agnostic: they are stored per host, not per origin. So:

1. Each launch picks a new random port → a new cookie name → a new cookie row.
2. Every later request to 127.0.0.1 sends all previously minted cookies, because none of them are scoped to a port.
3. Node's HTTP server caps request headers at 16 KiB (maxHeaderSize). Once the accumulated cookies cross it, every index request is answered 431, and the shell can never authenticate again — a permanent brick that no restart fixes.

A rough budget: ~220 bytes per cookie (47-byte name, ~170-byte signed value) → the ceiling is around 70 cookies, i.e. about 70 launches within the 30-day cookie lifetime. Anyone who launches the app more than a couple of times a day reaches this in a few weeks.

Suggested fixes

In order of preference:

1. Stop keying the cookie by port. Use dsh-auth- + hash(normalized hostname [+ scheme]) as the name and keep the full authority (host and port) inside the signed payload, which isAuthenticated already compares against the request. The browser then holds one cookie per host, replaced on every launch, and cross-port reuse still cannot authenticate because the payload's authority will not match.
2. Prune on mint. When issuing a new cookie, remove other dsh-auth-* cookies for the same host from the session's cookie store (for a browser, this means emitting expiring Set-Cookies for the stale names).
3. Treat 431 as recoverable. Clear the host's cookies and retry the launch once, and surface the real status code instead of "Web authentication failed" — the current message sent me looking at credentials, plugins and the credential store for a while.

Workaround (for anyone hitting this today)

Close every desktop window, then delete only the accumulated auth rows from the cookie database (back it up first — the file is locked while the app runs):

DELETE FROM cookies WHERE name LIKE 'dsh-auth-%';

Database path: %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies (SQLite). Restarting afterwards works immediately; the app mints a fresh cookie. In browser mode, clear the 127.0.0.1 cookies for the Web UI instead.

Happy to provide the NetLog capture and the standalone probe script if they help.