Desktop app fails to start after enough launches: authority-bound auth cookies are never purged, and overflow Node's 16 KB maxHeaderSize

[nightoperator2000]

Summary

On the desktop app, repeated launches eventually make startup fail every time with:

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)

The cause is not credentials, token state, or network. It is that the browser-session
cookie name is derived from the Host authority, which includes the random listen port,
and issuance never removes sibling cookies. Cookies do not scope by port, so every
historical cookie is sent on the same Cookie request header. After enough launches that
header crosses Node's default maxHeaderSize = 16384, the Host answers 431, and the
desktop shell reports it as an authentication failure.

Where this lives in the source

packages/client/connection/src/browser-auth.ts

• cookieName(authority) = COOKIE_PREFIX + base64url(sha256(authority)) — L116
• requestAudience() returns url.host, so the port is part of the name — L79-88
• issuance writes exactly one set-cookie and performs no sibling cleanup — L284, L344
• authenticate() looks the cookie up by name derived from the current authority, then
  requires payload.authority === authority — L375-380

That last point is the important one: a cookie issued for a previous port can never
authenticate again. Those rows are pure dead weight — so deleting them is
behaviour-preserving, not a workaround with side effects.

Measurements

Each cookie is ≈ 228 bytes (name 52 + value 173 + 3 separator bytes).

An injected-cookie sweep against a running Host:

cookies	Cookie header	status
60	13,078 B	303
70	15,258 B	303
72	15,694 B	303
80	17,438 B	431

On the affected machine, real startup broke at 71 accumulated cookies.

Note the discrepancy honestly: the synthetic sweep still answered 303 at 72, while the real
desktop request failed at 71. The synthetic request carries far fewer accompanying headers
than the shell's net.fetch (UA, Accept, Sec-Fetch-*, …), so the real break point is
earlier than the sweep suggests. Treat the sweep as a lower bound, not the threshold.

Why the error message misleads

Two hops use different requests:

• authenticateWebHost() — plain Node fetch, redirect: 'manual', no cookies
  → clean 303 + Set-Cookie → "authenticated"
• connectDesktopWelcome() — net.fetch(url, { credentials: 'include' }),
  sends every accumulated cookie → header too large → 431 → throws
  Web authentication failed

The first hop succeeds and the second fails, so the message blames authentication while the
actual condition is HTTP header size. This is worth fixing in the message itself — it sends
readers toward credentials.

Suggested fixes

1. Purge sibling dsh-auth-* cookies at issuance. Safe by the payload.authority
   check above. Caveat: cookie scope ignores port, so if two instances must run
   concurrently, purge only siblings whose authority is not currently listening.
   A simple total-count cap is an equally acceptable alternative.
2. Cap the count (drop oldest past N).
3. Raising maxHeaderSize only moves the break point; it does not stop the accumulation.

⚠️ One tempting fix is not sufficient on its own: making the cookie name fixed
(dropping the port). Cookie scope ignores port, so two instances on different ports would
overwrite each other's single-named cookie; each then fails the payload.authority check
and re-issues — they ping-pong. A fixed name is fine only if exactly one instance ever runs.

User-facing workaround

Quit the app completely first (a running app rewrites the jar from memory), then:

sqlite3 "$HOME/Library/Application Support/@deepseek-ai/dsh-desktop/Cookies" \
  "delete from cookies where name like 'dsh-auth-%';"

No re-login is needed — the shell re-issues a cookie from the launch URL on the next start.
Delete only the dsh-auth-% rows; do not delete the database.

Environment

• macOS (arm64), DSH desktop app, developer preview
• Node default maxHeaderSize = 16384, unmodified