Desktop app fails to start after ~68 launches: accumulated dsh-auth-* cookies overflow the 16 KB header limit -> 431 -> "desktop welcome: Web authentication failed"

[chuilian]

Summary

After ~68 launches, the macOS desktop app stops starting. Deterministic, not flaky:

应用无法启动或已意外停止。
desktop welcome: Web authentication failed

Environment: @deepseek-ai/dsh-desktop 0.2.1-rc.5 · Electron 44.7.0 · Node 24.21.0 · darwin arm64.

Cause: the Electron session cookie jar accumulates one dsh-auth-* cookie per launch. At ~68–71 entries the Cookie request header exceeds Node's default http.Server maxHeaderSize (16384 bytes), the host answers 431, and the shell treats any non-2xx as an authentication failure.

Root cause chain

1. Random port per launch. @deepseek-ai/dsh-desktop-host/lib/index.js:236-240 hardcodes ["--no-open","--host","127.0.0.1","--port","0"].
2. Cookie name is derived from the authority. @deepseek-ai/dsh-client-connection/lib/index.js:335-336: "dsh-auth-" + base64url(sha256(authority)); for http the audience is host:port (:152-159). New port → new name → the old cookie is never overwritten.
3. Nothing ever collects the old ones. Max-Age is 30 days by default, and cookies are not port-isolated, so every request carries the whole history.
4. Header limit. @deepseek-ai/dsh-host-webserver/lib/index.js:413 calls createServer(listener) without a maxHeaderSize, i.e. Node's 16 KB default.
5. The real status code is swallowed. connectDesktopWelcome (app.asar/lib/main.js:8886) throws a generic "desktop welcome: Web authentication failed"; the 431 never reaches the crash log.

Measured against the real host: 70 cookies (16,256 B) → 200; 71 cookies (16,485 B) → 431. Chromium's extra request headers lower the practical threshold to ~68.

Evidence

• Store: ~/Library/Application Support/@deepseek-ai/dsh-desktop/Cookies (SQLite), 71 rows, all dsh-auth-*, 16,117 B of name+value.
• Manual host launch + curl token→cookie flow: host is healthy, returns 200 with a valid cookie and 401 without.
• Clearing the jar → app starts normally (app.boot, store.snapshot.ok); restoring the 71 rows → identical crash. Reproduced twice in both directions.
• Header-size sweep (Cookie: <k cookies> → status): 250 cookies' worth (16,118 B) → 200; 255 (16,438 B) → 431.

Suggested fixes (any one removes the crash)

• a. Shell-side reset. Before connectDesktopWelcome, delete dsh-auth-* cookies for 127.0.0.1 from the default session, or run the main window in a non-persistent session partition.
• b. Header limit. Expose maxHeaderSize on dsh-host-webserver (and default it to 64 KB) instead of inheriting Node's 16 KB.
• c. Diagnostics. Include the HTTP status in the thrown error — desktop welcome: Web authentication failed (HTTP 431) — so a crash log points at the cause.

Related sharp edge (not a bug, but silent failure)

Lowering cookieMaxAgeDays on a running host (a cordis patch hot-reload) invalidates every already-issued cookie at once: BrowserAuth.authenticate() compares payload.expiresAt - payload.issuedAt against the current maxAgeMilliseconds (@deepseek-ai/dsh-client-connection/lib/index.js:563-568). The desktop shell captures its cookie once at startup (main.js:12191) and never re-issues, so the UI sits at connection.connecting ("重新连接中") forever — a page reload does not help, only an app restart. We hit exactly this while rolling out the workaround below. A config change that cannot be repaired without a restart probably deserves a warning or a forced re-issue path.

Workaround in use here

~/.dsh/profiles/desktop/cordis.patch.yml sets cookieMaxAgeDays: 5, bounding the jar at ~25 entries (≈5.7 KB) against a 68-entry crash line. Tradeoff: a continuous 5+ day uptime leaves the client unauthenticated until restart.

[dreanzy]

Independent reproduction on Windows, same conclusion — plus one cross-check that explains why the in-app recovery buttons ("禁用第三方插件 / 备份 profile patch 并重启") never helped.

Environment

• @deepseek-ai/dsh-desktop 0.2.2-rc.1 (Electron 44.7.0, Node 24.21.0), Windows 11 x64
• 11 consecutive crash logs, all identical: desktop welcome: Web authentication failed at connectDesktopWelcome (app.asar/lib/main.js:16856), zero error-level renderer output

Measurements

• Cookie store %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies (SQLite): 71 rows, all dsh-auth-*, host_key = 127.0.0.1, 16,021 B of name+value → assembled Cookie header 16,090 B.
• Replayed that exact Cookie string against a default node:http server with the usual browser headers (UA / sec-ch-ua* / accept*) → 431. Same server, no cookie header → 200. Consistent with your 70→200 / 71→431 sweep.

Extra evidence: the timestamp ordering pins the status code to 431

• Last successfully stored cookie: 2026-11-05T11:04:52Z
• First crash: 2026-11-05T11:05:45Z
• After that, no new cookie is ever written, even though each retry adds another crash log — the 431 is returned before the host's authentication handler runs, so Set-Cookie never appears.

That is also why disabling third-party plugins cannot help: the failure happens in the shell's welcome handshake, before any profile patch is applied.

Suggested fix, in order of preference

• Root fix — stop the name from growing. Deriving the cookie name from host:port (random port per launch) is what makes every launch mint a new entry. Keying the name on a stable authority (e.g. dsh-auth-desktop) would bound the jar at one entry per host, and a raised maxHeaderSize would stop being load-bearing.
• Shell-side cleanup as you suggest (a): drop dsh-auth-* for the loopback origin before connectDesktopWelcome, or use a non-persistent partition.
• Include the status in the thrown error (your c) — a 431 in the crash log would have made this a five-minute diagnosis.
• Platform-specific paths in docs: on Windows the jar lives under Network\Cookies, not at the profile root, so the workaround instructions need a per-platform path.

Workaround that unblocked it here: delete the 127.0.0.1 rows (the profile holds no other cookies), then launch — the jar is rebuilt with a single entry and the welcome handshake succeeds.