Desktop fails to start with "desktop welcome: Web authentication failed" after ~70 launches (auth cookies accumulate, one per launch, never pruned)

[lingxujp]

Summary

On Windows, @deepseek-ai/dsh-desktop 0.2.1-rc.2 eventually refuses to start. A dialog appears:

DeepSeek Harness is unavailable
The application could not start or stopped unexpectedly.
desktop welcome: Web authentication failed

The cause is not a corrupted install or a bad plugin: the app writes one new authentication cookie per launch into its own Network\Cookies store, on a new loopback port each time, and never removes the old ones. After ~70 launches the accumulated Cookie: header for 127.0.0.1 exceeds Node's default 16 KB request-header limit, so the internal welcome handshake fails and startup aborts.

Environment

OS	Windows (Chinese locale)
App	@deepseek-ai/dsh-desktop 0.2.1-rc.2
Electron	44.7.0
Node (bundled)	24.21.0
App data	%APPDATA%\@deepseek-ai\dsh-desktop
Install path	D:\Program Files\deepseek\

Crash log evidence

%APPDATA%\@deepseek-ai\dsh-desktop\logs\crash-2026-10-24T00-44-35-982Z-host.log (8 such files within 2 minutes, one per restart attempt):

app: @deepseek-ai/dsh-desktop 0.2.1-rc.2
electron: 44.7.0
node: 24.21.0
phase: startup
Error: desktop welcome: Web authentication failed
    at connectDesktopWelcome (file:///D:/Program%20Files/deepseek/resources/app.asar/lib/main.js:8886:31)

Cookie store evidence

%APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies (SQLite, Chromium schema), parsed after a failed start:

• 71 rows, all with host_key = 127.0.0.1
• cookie name = dsh-auth- + 43 random chars (52 chars total)
• value length = 173 bytes, stored in plaintext (encrypted_value length = 0)
• is_httponly = 1, is_secure = 0, expiry 2026-11-16

Per-cookie header cost: name(52) + "=" (1) + value(173) + "; " (2) = 228 bytes.
71 × 228 ≈ 15.9 KB, which together with ordinary request headers crosses the Node.js default --max-http-header-size of 16384 bytes. The failure threshold sits between 70 and 71 cookies.

Creation timestamps (UTC) map 1:1 to launches:

10-17 15:36 → 10-24 00:44, per day: 14 / 6 / 2 / 18 / 6 / 12 / 9 / 4
last cookie created 00:44:21 UTC, first crash log 00:44:24 UTC (3 s later)

So the count only ever grows, at ~9 launches/day → the bug returns about one week after a clean start, which matches the reported "it worked fine for a while, then suddenly stopped starting".

Why it is a loopback-port problem

The desktop app serves its UI on 127.0.0.1:<random port> and mints a fresh per-launch auth cookie for that origin. Because the port changes, the cookie's name is never reused, so the normal "replace existing cookie" path never triggers — every launch adds one more row for the same host.

Observed ports across launches differed each time (e.g. 51765 → 53574 → 55094).

Reproduction

1. Start the desktop app and let it come up; quit it. Repeat ~70 times (or seed Network\Cookies with N dsh-auth-* rows for 127.0.0.1).
2. On the launch that pushes the count past the header limit, the app exits with the dialog above and never shows a window.
3. Fully quit, rename Network\Cookies away, start again → app starts normally.

Suggested fixes (any one of these)

1. Prune on startup: before the welcome handshake, delete dsh-auth-* cookies for 127.0.0.1 that do not match the current launch (or that are older than N days). This is the minimal fix and needs no port changes.
2. Reuse a stable port (or a stable cookie name) so the existing replacement logic applies.
3. Bound the header: derive the auth value from a short-lived in-memory secret instead of persisting one cookie per launch.
4. Guard: if the accumulated header would exceed the limit, clear the store and retry once instead of failing startup.

Current workaround

Fully exit the app, then rename (do not delete blindly) %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies (plus Cookies-wal / Cookies-shm if present) and restart. The file is exclusively locked while the app runs, so this must be done with the app closed.

I wrapped this into a small launcher that does it automatically on every start, keeping the last 10 backups — that turns "app silently dies once a week" into "app always starts".

---

中文摘要

Windows 上 DSH 桌面端跑约 70 次之后就无法启动，弹窗写 desktop welcome: Web authentication failed。真因是每次启动都往自己的 Network\Cookies 里写一条新的、绑定当时随机端口 127.0.0.1 的认证 cookie（dsh-auth- + 43 位随机名，值 173 字节），从不清理；71 条时累计 Cookie: 头约 15.9 KB，越过 Node 默认 16 KB 的请求头上限，启动握手失败。

证据：崩溃日志 8 份（crash-*-host.log，connectDesktopWelcome at main.js:8886）；cookie 库 71 条全部 host_key=127.0.0.1，按天新增 14/6/2/18/6/12/9/4，最后一条创建后 3 秒即崩溃；单条头部开销 228 字节，阈值落在 70→71 之间；按每天 9 次启动算约一周复发。

建议：启动时清掉不属于本次启动的 dsh-auth-*；或固定端口/固定 cookie 名；或超限时清库重试一次，而不是直接启动失败。

[Xmiss9]

Independent Windows reproduction — and the 70/71 boundary verified by direct measurement

Your analysis matches mine, and I can close the one gap: you inferred "the threshold sits between 70 and 71"; here is the boundary measured directly on both sides.

Environment: Windows 11 x64 · @deepseek-ai/dsh-desktop 0.2.1-rc.2 · Electron 44.7.0 · Node 24.21.0 · install D:\X\xxrj\DeepSeek · userData %APPDATA%\@deepseek-ai\dsh-desktop (Chinese locale, same as yours). Network\Cookies: 71 rows, all dsh-auth-*, all host_key='127.0.0.1'. Crash log identical (main.js:8886:31 / 12195:22), 6 crashes in 4 minutes.

Direct boundary test

Started the same Host standalone (dsh-desktop-host/lib/index.js, random port 5093) and varied only the Cookie: header size:

Cookie: header	bytes	Host response
freshly minted cookie only	224 B	200 (index served)
fresh + 60 stale dsh-auth-*	13 824 B	200
fresh + 71 stale dsh-auth-*	16 316 B	431
padding only (no dsh-auth cookie at all)	16 002 B	401 (normal auth path)
padding only (same)	16 302 B	431

Two things this settles:

1. 60 stale cookies still work, 71 do not — the cutoff is exactly Node's default maxHeaderSize (16 384 B), so "between 70 and 71" is confirmed, not just estimated.
2. Padding with zero auth cookies also returns 431 at 16 302 B — ruling out any "bad signature / corrupted value / auth-logic" theory. It is purely header size, which also explains why the token exchange always succeeds (authenticateWebHost() uses a cookieless Node fetch, so it never sends the jar) and only the net.fetch in connectDesktopWelcome() dies.

Extra confirmations

• Same exe with --user-data-dir=<empty dir> → starts into the workspace normally (rules out install/network/account/plugin).
• Deleting only Network\Cookies (backed up first; no code or profile changes) → handshake 401 → 200, app starts, zero crash logs afterwards.
• Recurrence: one new cookie per launch, Max-Age=2592000, so it returns after ~70 launches. The browser dsh web on a fixed port is unaffected (stable cookie name ⇒ replacement path triggers), so this is desktop-only.

One addition to your fix list

Your four suggestions all hold (pruning on startup is the minimal one). Add a fifth, nearly free:

• include authenticated.status in the thrown error (desktop welcome: Web authentication failed (HTTP 431)). The current wording sends everyone hunting credentials/proxies/plugins, which is the most expensive part of this bug.

Related

• Full report with repro commands (filed in my repo because deepseek-ai/deepseek-harness has Issues disabled): dsh-desktop 0.2.1-rc.2: startup permanently fails after ~70 launches — accumulated dsh-auth cookies overflow Node's 16KB header limit (431 → desktop welcome: Web authentication failed) Xmiss9/wanwan#1
• Same cause, Chinese, earlier: [Bug] 桌面端每次启动新发一枚认证 cookie，约 70 次后请求头超过 16 KB，启动直接失败（431 → "Web authentication failed"） #10632
• Third-party records: TommyFang2077/dsh-linux-desktop#40, Minglink/DeepSeek-Harness-Desktop#2 (note: their secondary claim that net.fetch ignores the session cookie store is contradicted by the single-cookie and padding results above — the only sufficient cause is header size).

Your launcher workaround is a good stopgap; pruning by cookie name at startup is basically the same thing inside the app.