[Desktop 0.2.1-rc.5] Startup crash "desktop welcome: Web authentication failed" — dsh-auth-* cookies accumulate past the host's 16KB header limit → 431 (source evidence + repro)

[big0cat0cat]

TL;DR

The desktop host listens on a random port each launch and mints one persistent cookie named dsh-auth-<base64url(sha256("127.0.0.1:<port>"))> per port, valid 30 days. The Electron side never deletes old cookies. Each pair is ~226 bytes, so after ~70 launches the Cookie header pushes total request headers past Node's default 16KB limit; the host answers the index request with 431, and the app's connectDesktopWelcome() treats any non-2xx as auth failure:

Error: desktop welcome: Web authentication failed

From then on every launch dies on its first request (the cookie count never drops), so the app is bricked until the user manually wipes the cookie DB. Reinstalling does not help.

Environment

• @deepseek-ai/dsh-desktop 0.2.1-rc.5, Electron 44.7.0, Node 24.21.0 (crash log header)
• macOS 15.7.3 arm64
• First occurrence 2026-11-04 19:31 after ~70 launches over 11 days; 6 consecutive startup crashes 19:31–19:39 (host / web-boot / main / renderer phases)

Source evidence (extracted from app.asar, matches 0.2.1-rc.5)

1. Cookie name binds the port — lib/types/browser-auth.js:

const COOKIE_PREFIX = "dsh-auth-";
function cookieName(authority) {
  return COOKIE_PREFIX + encodeBase64Url(createHash("sha256").update(authority).digest());
}

authority is the normalized scheme://host:port of the listener. Host ports are ephemeral ⇒ every launch produces a brand-new cookie name. Verified locally: base64url(sha256("127.0.0.1:53643")) exactly matches the cookie stored for the running session.

2. 30-day lifetime, no eviction — the package's own doc string: "Cookies carry an absolute issue/expiry interval, defaulting to 30 days through cookieMaxAgeDays". Live DB confirms expires_utc − creation_utc = 30 days.

3. No cleanup path exists — full 182MB asar scan: zero cookies.remove(; the only cookies.clear( belongs to the ACP in-memory cookie store (MemoryAcpCookieStore), not the Electron persistent store.

4. App collapses all non-2xx into "auth failed" — connectDesktopWelcome():

const authenticated = await send(authenticatedUrl, { credentials: "include" });
await authenticated.body?.cancel();
if (!authenticated.ok) throw new Error("desktop welcome: Web authentication failed");

5. Host never raises the limit — --max-http-header-size appears only inside bundled undici doc comments; the host http.createServer call passes no maxHeaderSize, so the 16384-byte default applies.

Local cookie DB evidence

• DB: ~/Library/Application Support/@deepseek-ai/dsh-desktop/Cookies
• The DB file was rebuilt at 19:40:55 (birthtime), right after the last crash, so the accumulated 71 rows are gone; the two surviving rows still fingerprint the mechanism: same host_key=127.0.0.1, different names (two different launch ports), each 226 bytes (name 52 + value 173 + 1 separator), value shape v1.<126 chars>.<43 chars> matching encodeCookie(), expiry exactly +30d.
• Timeline matches: crash logs at 19:31:15 (host), 19:31:28 (web-boot), 19:31:41 & 19:32:26 (main), 19:38 (renderer), 19:39:34 (host) → DB rebuild + successful launch 19:40:55.

Reproduction

A. Natural: use the desktop app normally; ~70 launches (~10 days at my cadence) ⇒ bricked.

B. Artificial (no accumulation needed) — replay 70 real-sized cookies against any local server (host's own node, Node 24.21.0):

const http = require("http");
const name = "dsh-auth-" + "A".repeat(43);
const value = "v1." + "B".repeat(126) + "." + "C".repeat(43); // 173, same shape as encodeCookie()
const cookie = Array.from({length: 70}, (_, i) => name + i + "=" + value).join("; ");
const srv = http.createServer((q, s) => { s.writeHead(200); s.end("ok"); });
srv.listen(0, "127.0.0.1", () => {
  const p = srv.address().port;
  const req = http.request({host: "127.0.0.1", port: p, path: "/",
    headers: {Cookie: cookie, "User-Agent": "Mozilla/5.0", "Accept": "text/html",
              "Accept-Language": "zh-CN", "Accept-Encoding": "gzip, deflate, br"}}, r => {
    console.log("n=70 →", r.statusCode);
    srv.close();
  });
  req.end();
});

Measured on my machine: with typical Chromium request headers, n=69 → 200, n=70 → 431 (total ≈16.6KB); with the Cookie line alone, n=71 → 431.

Impact

• Every long-term user hits this around launch 看不到模型输出，从轨迹里看是ASSISTANT #70 with no warning; app fails to start until manual cookie-DB surgery.
• Surviving workaround: quit the app, DELETE FROM cookies WHERE name LIKE 'dsh-auth-%'; in the DB (or keep only the current port's row), relaunch. I've deployed a weekly cleanup that hashes all local TCP listen ports and keeps only the live cookie.

Suggested fixes (any one suffices)

1. When minting the new cookie at startup, evict stale dsh-auth-* cookies from the Electron session / cookie store.
2. Persist/reuse a fixed loopback port so the cookie name stays stable.
3. http.createServer(..., { maxHeaderSize: 65536 }) on the host.
4. (Mitigation) In connectDesktopWelcome(), branch on 431 with an explicit error message instead of the generic "Web authentication failed" — it would have saved hours of misdiagnosis ("cookie 坏了"/login issues).

Notes

• Cookie values are auth credentials and are redacted everywhere in this report; cookie names are authority hashes and safe to share.
• Crash logs from Nov 1–2 ("web boot: N entries did not activate") are a separate plugin-bundle issue and intentionally excluded.

[0xJingwei]

Additional synthetic regression evidence for the same macOS arm64 0.2.1-rc.5 startup failure:

Using an isolated Electron userData directory and synthetic cookies only, the shipped connectDesktopWelcome failed with the reported message when the default jar contained 71 auth-sized cookies; the Electron HTTP response was 431. No real credential values or authentication URLs were used in the reproduction.

A small candidate fix reuses the exact current Host cookie already returned by the existing authenticateWebHost() Node fetch: capture it in a per-Host-generation constant, use Node fetch with that explicit Cookie header for welcome requests, and return that same constant from the account-watch cookie callback. This avoids the persistent Electron default cookie jar entirely and allocates no additional Session partitions. Host auth checks and renderer forwarding remain unchanged.

The candidate passed 12 separate-port synthetic Host generations: welcome handshake and authenticated RPC worked, each cookie callback contained only its own Host cookie, later generations did not invalidate earlier ones, and the synthetic persistent/account cookie jar stayed unchanged. This is isolated candidate validation; it has not been deployed to the production desktop and does not establish end-to-end account sign-in compatibility. A local packaged-app patch changes the vendor signature, so an official signed fix would be preferable.

For the real incident, the original failed request's HTTP status was not captured. Cookie metadata, a same-size synthetic 431 reproduction against the Host, and recovery after isolating the local-auth cookie store support the diagnosis. Please distinguish HTTP 431 in startup diagnostics without logging cookie/token values.