[desktop] Startup fails after ~70 launches: desktop welcome: Web authentication failed (cookie jar overflow → HTTP 431)

[dawu-2026]

同性问题已有更早、更完整的讨论：#11095（多平台复现，含源码定位）与 #10496。本条保留为独立复现记录（Windows 11 x64 / 0.2.1-rc.5），讨论请以 #11095 为准。

Summary

After roughly 68–70 launches, dsh-desktop stops starting forever with:

The application could not start or stopped unexpectedly.
desktop welcome: Web authentication failed

It is not an account/network problem. The Host answers 431 Request Header Fields Too Large,
and the desktop shell maps every non-2xx to a generic auth error.

Cause: the Host mints a new browser-session cookie on every launch whose name embeds
host:port. The port is random per launch, so each start adds one more dsh-auth-* cookie for
127.0.0.1 that is never removed (30-day expiry). Chromium sends all of them on the
launch-URL redirect; once Cookie plus the other request headers exceed Node's default
maxHeaderSize (16 KiB), the Host rejects the request with 431.

Environment

App	@deepseek-ai/dsh-desktop 0.2.1-rc.5 (nightly feed download.deepseek.com/dsh-desk/feeds/win-x64/)
Chromium / Node	Electron 44.7.0 / Node 24.21.0
OS	Windows 11 x64 (win32 x64)
Crash report	%APPDATA%\@deepseek-ai\dsh-desktop\logs\crash-2026-11-01T08-04-50-928Z-host.log
Failure	Error: desktop welcome: Web authentication failed at connectDesktopWelcome (.../resources/app.asar/lib/main.js:8886:31)

Root cause — three sites in master

1. One cookie per launch, never cleaned up
packages/client/connection/src/browser-auth.ts:116

function cookieName(authority: string): string {
  return COOKIE_PREFIX + encodeBase64Url(createHash('sha256').update(authority).digest())
}

authority is host:port (see requestAudience), so every launch — random port — creates a
new cookie name for the same host 127.0.0.1. sessionCookie (:131) writes
Max-Age=<30 days>; Path=/; HttpOnly; SameSite=Strict. Nothing ever deletes the old ones.

2. The Host's HTTP server keeps Node's default 16 KiB header limit
packages/host/webserver/src/index.ts

this.server = createServer(listener)          // no maxHeaderSize → default 16384
...
this.server = createServer$1({ ... })         // https variant, same omission

3. The desktop shell hides the real status
apps/desktop/src/welcome-backend.ts:49

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

Electron net.fetch follows the Host's 303, the redirect target GET / carries every
accumulated cookie, and the 431 (or any other status) collapses into the same message.

Measured evidence (real profile, 2026-11-01)

• Cookie DB %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies: 71 rows, all
  host_key='127.0.0.1', path='/', names dsh-auth-<hash>, one per distinct source_port.
• Serialized Cookie header: 16,104 bytes; plus Chromium's usual headers ≈ 16.7 KB.
• http.maxHeaderSize under the app's own Node 24.21.0: 16384.

Experiment	Result
Fresh --user-data-dir	starts fine
Copy of the same profile without Network\Cookies	starts fine
Original profile	crashes (8 times on 2026-11-01)
Probe: 68 cookies / 15,424 B Cookie header	200
Probe: 70 cookies / 15,878 B	431, HPE_HEADER_OVERFLOW
Probe: 71 cookies / 16,104 B	431, HPE_HEADER_OVERFLOW

The probe is a plain node:http server created the way the Host creates it, hit with a cookie
header built from the real profile values plus Chromium-shaped headers.

Deterministic reproduction (no 70 restarts needed)

1. Start any node:http server with default options (or the real Host).
2. Send GET / with Cookie: <70 × "dsh-auth-<43 chars>=<173 chars>"> (≈15.9 KB) and a normal
   Chromium header set → the server emits clientError HPE_HEADER_OVERFLOW and answers 431.
3. In the desktop shell that 431 becomes desktop welcome: Web authentication failed.

Real-world reproduction is just "launch the app ~70 times"; that is what the profile above shows
(created dates spread over 2026-10-15 … 2026-11-01, ~14 on the busiest days).

Suggested fixes

• A (minimal, highest value) — raise the Host's limit:
  createServer({ maxHeaderSize: 64 * 1024 }, listener) (same for the https variant).
  Removes the cliff; nothing else changes.
• B (bounded jar) — do not name the cookie after host:port. The signed payload already
  carries authority ({version, authority, issuedAt, expiresAt}) and isAuthenticated
  re-checks it, so a fixed per-host name is enough and keeps the jar at exactly one cookie
  per host instead of one per launch.
• C (defensive) — sweep stale 127.0.0.1 dsh-auth-* cookies before
  connectDesktopWelcome so already-poisoned profiles heal on upgrade.
• D (diagnosability) — include the status in the error:
  throw new Error(\desktop welcome: Web authentication failed (HTTP ${authenticated.status})`)`.
  One line, and this whole investigation would have started from the answer instead of the symptom.

A/B alone make this unreachable; C+D are cheap insurance.

Impact

Any desktop user hits a hard, permanent startup failure after enough launches, with no
recovery path in the UI (the dialog only offers Exit / Restart / "disable third-party plugins and
back up profile patch"). The same 16 KiB wall also hits dsh web when its tokenized launch URL is
opened in one browser profile ~70 times.

User-side workaround

Quit the app, then delete %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies
(the app recreates it; make a backup first). Startup then succeeds immediately.

---

中文摘要

dsh-desktop 启动约 68–70 次后会永久启动失败，报 desktop welcome: Web authentication failed。
真实原因是 Host 返回了 431（请求头过大），桌面壳把所有非 2xx 都当成认证失败。

三处成因（master 均未修）：

1. packages/client/connection/src/browser-auth.ts:116 —— cookie 名是
   dsh-auth-<sha256(host:port)>，端口随机 → 每次启动新增一条、30 天过期、从不清理，
   127.0.0.1 下越攒越多。
2. packages/host/webserver/src/index.ts —— createServer(listener) 没设 maxHeaderSize，
   沿用 Node 默认 16 KiB。
3. apps/desktop/src/welcome-backend.ts:49 —— net.fetch 跟随 303 后，431 被压成
   "Web authentication failed"，看不出真实原因。

实测：71 条 cookie，Cookie 头 16,104 字节，加常规头 ≈16.7 KB；68 条 → 200，70/71 条 → 431
HPE_HEADER_OVERFLOW。删掉 Network\Cookies 立刻恢复正常。

建议：A) Host 端把 maxHeaderSize 提到 64 KiB；B) cookie 名不再绑定端口（签名里已有
authority，可校验）；C) 桌面启动前清理旧的 dsh-auth-*；D) 错误信息带上 HTTP 状态码。
A+B 即可根治，C+D 是低成本保险。

[drscrewdriver]

pnpm install dsh-cookie-cleaner

① 先看现状（客户端开着也能跑，只会告诉你读不到）

& "$env:USERPROFILE.dsh\profiles\desktop\node_modules.bin\dsh-cookie-cleaner.cmd"

② 完全退出客户端：托盘图标 → 退出，并确认进程列表已无 DeepSeek Harness

Get-Process | Where-Object { $_.ProcessName -match 'DeepSeek|dsh' } # 应当没有输出

③ 清理（先看会删几条，再真删）

& "$env:USERPROFILE.dsh\profiles\desktop\node_modules.bin\dsh-cookie-cleaner.cmd" --clean --dry-run
& "$env:USERPROFILE.dsh\profiles\desktop\node_modules.bin\dsh-cookie-cleaner.cmd" --clean

[Heybinshao]

Independent confirmation on macOS arm64, @deepseek-ai/dsh-desktop 0.2.2-rc.1 (current latest release, published 2026-11-04). Still reproducible; I also searched for open PRs touching dsh-auth / maxHeaderSize / welcome-backend and found none, so this appears unfixed as of the latest build.

Measured on the affected install (read directly from the Electron cookie store at ~/Library/Application Support/@deepseek-ai/dsh-desktop/Cookies):

• 71 cookies, all on host 127.0.0.1, every name of the form dsh-auth-<43 random chars> — a fresh random name per launch, so no cookie ever gets overwritten
• each cookie is ~255 bytes of name+value; 18,105 bytes of cookie payload before request headers

Fully quitting the app and deleting the dsh-auth-* rows from that cookie store restored startup on the next launch (verified: main + host + renderer processes up, no new crash log). Session data under ~/.dsh was untouched.

One extra data point for the bounded-jar suggestion above: since the name is random per launch rather than derived from the authority, a fixed name per host would keep the jar at exactly one entry regardless of launch count.

[Heybinshao]

The upstream PR route is closed to external contributions on this repo — CONTRIBUTING.md: "We are sorry that we cannot accept external pull requests at the moment" (enforced by the Reject ALL Create/Delete/Force ruleset: CreatePullRequest fails for external accounts, verified with a probe PR in a personal fork). So here is the diagnosability fix (suggestion D from this thread) as a self-contained patch against current master:

diff --git a/apps/desktop/src/welcome-backend.ts b/apps/desktop/src/welcome-backend.ts
index 15b0932..750d491 100644
--- a/apps/desktop/src/welcome-backend.ts
+++ b/apps/desktop/src/welcome-backend.ts
@@ -58,7 +58,7 @@ export function connectDesktopWelcome(
       headers: { 'content-type': 'application/json', cookie },
       body: JSON.stringify({ type: 'client-request', rpcId, method, payload: { args: request.args } }),
     })
-    if (!response.ok) throw new Error('desktop welcome: Web request failed')
+    if (!response.ok) throw new Error(`desktop welcome: Web request failed (HTTP ${response.status})`)
     const envelope: unknown = await response.json()
     if (!record(envelope) || envelope.type !== 'server-response' || envelope.rpcId !== rpcId
       || !record(envelope.result) || envelope.result.ok !== true) {

Crash reports would then carry desktop welcome: Web request failed (HTTP 431) instead of the opaque string, which is the one fact that identifies the cookie-jar overflow cause.

Tests (sparse-checkout workspace, pnpm exec vitest run from the repo root):

• apps/desktop/tests/welcome-host.spec.ts — 9 passed (directly exercises connectDesktopWelcome)
• apps/desktop/tests/account-backend.spec.ts — 5 passed (same import closure)

No test or snapshot asserts the old message string.