[Desktop][P0] Startup fails permanently after ~70 launches: dsh-auth-* cookies exceed Node's 16 KB header limit → HTTP 431, reported as "Web authentication failed"

[MaDuoDuoBaBa]

Environment

• App: @deepseek-ai/dsh-desktop 0.2.2-rc.1 (nightly)
• Electron 44.7.0 / Node 24.21.0 / macOS arm64 (Apple Silicon)
• Profile: desktop (the failure is in the shell↔Host handshake, before any plugin UI; third-party plugins are not required)

Summary

The desktop app stops starting after enough launches, with no way to recover from the UI.

Every launch, the Host mints a new browser-auth cookie on 127.0.0.1:

• name: dsh-auth- + base64url(sha256("127.0.0.1:<port>"))
• value: 173 chars, Max-Age=2592000 (30 days), Path=/, HttpOnly, SameSite=Strict
• the desktop Host always starts with --port 0, so the port (and therefore the cookie name) changes on every launch

Cookies are host-scoped, not port-scoped, and nothing prunes old ones. They accumulate. At ~70 cookies, the Cookie request header exceeds Node's default http.maxHeaderSize (16,384 B). The Host's HTTP parser answers 431 Request Header Fields Too Large before routing. connectDesktopWelcome() checks only response.ok and throws a generic desktop welcome: Web authentication failed, so boot aborts and the crash report contains no status code.

After the limit is crossed, every retry fails the same way (431 happens before a new cookie can be minted), so it never self-heals. Deleting the dsh-auth-* rows makes the same version start immediately.

Impact

• P0 for anyone who launches the desktop app often: deterministic once ~70 launches fall inside a trailing 30-day window (~2.4 launches/day).
• No in-product recovery; non-technical users are stuck until they clear the cookie jar or 30 days pass.
• The crash report says only "authentication failed", so support cannot diagnose it remotely.

Steps to reproduce

1. Fresh install, launch the desktop app normally ~71 times within 30 days (updates/restarts count).
2. From ~71 launches on, the app fails to start with desktop welcome: Web authentication failed.
3. Quit, delete dsh-auth-* from ~/Library/Application Support/@deepseek-ai/dsh-desktop/Cookies, relaunch → works again.

Header-limit proof without the app (script attached): a default http.createServer + 69 cookies of this size + normal request headers already returns 431; 71 is guaranteed.

Evidence (captured from a failed machine)

Item	Value
dsh-auth-* cookies at failure	71, all host 127.0.0.1, Path=/, HttpOnly
Cookie names	71 distinct (sha256("127.0.0.1:<port>"))
Cookie value length	173 chars each
Per-cookie header cost	52 (name) + 1 + 173 = 226 B
71-cookie header	16,186 B
Node http.maxHeaderSize (v24.21.0)	16,384 B
Left for request line + Host + UA	198 B → 431
Cookie lifetimes	exactly issued + 30d, spanning 2026-10-20 → 2026-11-11 (22 days, 71 launches)

Timeline (UTC+8):

• 00:03 — 71st cookie minted; that boot carried 70 cookies (15,958 B + Electron's own headers) and just passed.
• 00:39 / 00:40 / 00:42 / 00:45 — next launches carry 71 cookies → 431 → Web authentication failed → exit.
• 00:48 — delete the dsh-auth-* rows (VACUUM), relaunch → starts instantly.

The captured SQLite Cookies DB was 53,248 B; the rows are all dsh-auth-*, and each name maps to a different ephemeral port (verified: sha256("127.0.0.1:57713") equals the current cookie name).

Root cause (code)

@deepseek-ai/dsh-client-connection/lib/index.js:

function requestAudience(headers, secure) {
  const url = new URL(`${secure ? "https:" : "http:"}//${headers.host}`);
  return secure ? url.origin : url.host;      // "127.0.0.1:<ephemeral port>"
}
function cookieName(authority) {
  return "dsh-auth-" + encodeBase64Url(createHash("sha256").update(authority).digest());
}
// Max-Age default:
cookieMaxAgeDays: z.natural().min(1).default(30)

@deepseek-ai/dsh-host-webserver/lib/index.js: createServer(listener) — no maxHeaderSize override, so Node's 16 KB default applies.

lib/main.js (shell):

// 15839: Node fetch (no cookie jar) → 303 + Set-Cookie, succeeds
hostCookie = await authenticateWebHost(ready.url);
// 20387: Chromium net.fetch sends the whole jar → 431 here
welcomeBackend = await connectDesktopWelcome(ready.url, (input, init) => net.fetch(input, init), ...);
// 16857: any non-2xx collapses into one message
if (!authenticated.ok) throw new Error("desktop welcome: Web authentication failed");

That asymmetry (Node fetch OK, Chromium fetch 431) explains why the Host log calls the Host healthy while the shell reports an auth failure.

Proposed fix

P0, smallest change — prune stale auth cookies in the shell before the welcome fetch (the launch token re-mints one immediately):

// apps/desktop main.ts, in backend.start(), after host.start()
const jar = await session.defaultSession.cookies.get({ url: ready.url });
for (const cookie of jar) {
  if (cookie.name.startsWith("dsh-auth-")) {
    await session.defaultSession.cookies.remove(ready.url, cookie.name);
  }
}

P0, diagnostics — include the status and the cookie weight, and stop labeling it as a host failure:

if (!authenticated.ok) {
  const bytes = (await session.defaultSession.cookies.get({ url: ready.url }))
    .reduce((n, c) => n + c.name.length + c.value.length + 2, 0);
  throw new Error(`desktop welcome: Web authentication failed (HTTP ${authenticated.status}, cookies≈${bytes}B)`);
}

P1 — bound the set by design: stable cookie name per host with authority/id in the signed payload (bounded count for concurrent instances), or cookieMaxAgeDays: 1 plus pruning, instead of per-port names living 30 days.

P2 — regression test: seed 120 dsh-auth-* cookies, boot must reach the workspace; assert the cookie count does not grow with launches; assert a 431 surfaces as HTTP 431 in the crash report.

Workaround (app must be closed)

C="$HOME/Library/Application Support/@deepseek-ai/dsh-desktop/Cookies"
sqlite3 "$C" "delete from cookies where host_key in ('127.0.0.1','localhost','::1') and name like 'dsh-auth-%';"
sqlite3 "$C" "vacuum;"

Attachments

• dsh-431-evidence.zip
  • README.md — full report with the same evidence and acceptance criteria
  • repro-header-limit.mjs — header-limit repro on Node 24.21.0
  • cookie-inventory.csv — 71 rows, values redacted (prefix + length + issue/expiry only)
  • crash-excerpt.txt — sanitized crash-log lines

---

中文摘要

桌面版每启动一次就会在 127.0.0.1 上新增一条 dsh-auth-* Cookie（名字含随机端口，30 天有效），从不清理。Cookie 不区分端口，约 70 次启动后请求头超过 Node 默认的 16,384 字节，Host 返回 431；主进程只看 response.ok，把它统一报成 Web authentication failed，应用退出。失败后不会签发新 Cookie，重试无法自愈，只能删 Cookie 库或等 30 天过期。实测失败时库里有 71 条（53 KB），Cookie 头 16,186 B；删除后同版本立即恢复。建议桌面主进程在 welcome 前清理旧 dsh-auth-*，错误信息带上状态码与 Cookie 体积，并改用稳定 Cookie 名/短有效期，补一条“预置 120 条 Cookie 仍能启动”的回归测试。
dsh-431-evidence.zip

[xuyahang]

Cross-linking #12953, because the missing piece here is not diagnosis but shipping.

Commit 93bef27 (fix(desktop): remove legacy Host auth cookies from the default session, 2026-10-31) already fixes this on main, and it is not in 0.2.2-rc.1 - the newest release. Two checks on an installed 0.2.2-rc.1:

• GET /compare/93bef27...dsh-v0.2.2-rc.1 -> status: diverged, ahead_by: 74, behind_by: 2
• findstr /C:"removeLegacyHostCookies" resources\app.asar -> no match
  • control: findstr /C:"desktop welcome: Web authentication failed" -> match, so the search itself works

So every report in this thread is the expected behaviour of the shipped build, and manually deleting Network\Cookies is only a stopgap. Measured numbers (71 rows / 16,117 bytes; 16,044 B -> 401, 16,270 B -> 431), the interim cookieMaxAgeDays workaround, and the backport request are in #12953.