[Bug] Desktop startup fails with "desktop welcome: Web authentication failed" — per-launch dsh-auth cookies accumulate until the 16KB request-header limit returns 431

[zcluo]

Summary

The packaged desktop app eventually fails to start with Error: desktop welcome: Web authentication failed (phase: startup). The authentication flow itself is healthy — the cause is accumulation: every app launch mints a new 30-day dsh-auth-* cookie whose name embeds the Host's ephemeral port. Browsers scope cookies by domain but not by port, so the cookie store for 127.0.0.1 grows by one entry per launch. After a few dozen launches the Cookie header sent to the Host exceeds Node's default 16 KB request-header limit and the server answers 431 Request Header Fields Too Large. The welcome handshake treats any non-2xx as fatal, so startup fails.

Environment

• @deepseek-ai/dsh-desktop 0.2.2-alpha.2, win-x64 unsigned build, Electron 44.7.0, Node 24.21.
• The involved code paths (apps/desktop/src/welcome-backend.ts, apps/desktop/src/main.ts, packages/client/connection/src/browser-auth.ts) are unchanged across recent 0.2.x releases, so any long-installed copy is susceptible once its cookie jar fills. Onset is gradual: roughly tens of launches.

Reproduction

1. Launch and quit the packaged desktop app repeatedly — each launch binds a new ephemeral port and adds one cookie.
2. Once the accumulated 127.0.0.1 cookies push the Cookie request header over 16 KB, every launch fails at startup with desktop welcome: Web authentication failed, retried several times before the backend controller stops the Host.

Root cause

1. authorizeIndex in packages/client/connection/src/browser-auth.ts answers the authenticated launch URL (/?token=…) with 303 plus Set-Cookie: dsh-auth-<base64url(sha256(authority))>=…; Max-Age=2592000; Path=/; HttpOnly; SameSite=Strict, where authority is 127.0.0.1:<port> and the port is ephemeral per launch.
2. Browsers and Electron's Chromium cookie jar scope cookies by domain and path — not by port — so previous launches' cookies are never overwritten or expired: one new 30-day entry per launch accumulates under 127.0.0.1.
3. connectDesktopWelcome (apps/desktop/src/welcome-backend.ts) fetches the launch URL with net.fetch and credentials: 'include'; Chromium attaches all matching cookies — by then tens of KB.
4. The Host webserver is a Node http server with the default 16 KB max request-header size, so it responds 431, and the non-2xx becomes the fatal startup error.

Evidence

• Net-log capture of a failing launch: request header Cookie: [16186 bytes were stripped], response HTTP/1.1 431 Request Header Fields Too Large.
• The app's cookie store (userData/Network/Cookies) contained 142 dsh-auth-* entries, one per past launch.
• The flow itself is healthy end to end: against both a source checkout and the packaged runtime started standalone (resources/runtime/cli/bin/dsh.cmd web), token → 303 + Set-Cookie → follow with cookie → 200; a minimal Electron net.fetch repro also stores the cookie and follows the redirect correctly. The failure is purely accumulated header size.

Suggested fixes

Any of these would stop the accumulation:

1. Purge stale entries before the handshake: the desktop main process owns the Electron session; before connectDesktopWelcome, remove existing dsh-auth-* cookies for the Host origin (session.cookies.get + cookies.remove). Pruning inside authorizeIndex cannot name the old cookies — their names depend on past random ports.
2. Make the cookie name port-independent: derive the cookie name from the origin without the port, so each launch overwrites the previous entry; the signed payload's authority can keep binding the full audience if that guarantee matters.
3. Belt-and-braces: reduce the 30-day lifetime — today's cookies outlive their process by a month.

Workaround for affected users

Quit the app, delete the Chromium cookie store in the app's user-data directory — %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies on Windows (same Network/Cookies under the equivalent user-data path on macOS/Linux) — and relaunch. These cookies only carry per-launch local authentication, so nothing of value is lost. The failure will recur after a similar number of launches until the accumulation itself is fixed.