[Bug] Desktop 0.2.1-rc.3 (Windows x64): "desktop welcome: Web authentication failed" once per-port dsh-auth cookies overflow the 16 KiB header limit

[zrwangems]

Environment

• DeepSeek Harness Desktop 0.2.1-rc.3 (official Windows x64 installer, nightly channel, 2026-10-23)
• Windows 11 x64; Electron 44.7.0; Node 24.21.0
• dsh web (CLI 0.2.1-rc.2) on the same machine is unaffected; the browser GUI opens and authenticates normally
• Reproducibility: 5/5 launches once the cookie jar reaches 71 cookies; the launch immediately before that threshold still succeeded

Summary

Every Desktop launch mints a new dsh-auth-* cookie bound to 127.0.0.1:<random port> and never removes the previous ones. After about 70 launches the accumulated Cookie header exceeds Node's default 16 KiB HTTP header limit. The token-exchange request (70 cookies) still receives its 303, but the follow-up redirect (now 71 cookies) is rejected before the authentication handler runs, so the shell aborts with desktop welcome: Web authentication failed.

Steps to reproduce

1. Launch Desktop 0.2.1-rc.3 normally. Each launch adds one row to %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies (one per random host port).
2. Repeat until the jar holds 71 cookies for 127.0.0.1 (in our case ~10 days at 7–8 launches/day, 16,188 bytes of cookie data).
3. Launch again. Startup fails with the dialog below; neither Restart nor Disable third-party plugins, back up profile patch, and restart helps.

Observed

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

Host crash log (%APPDATA%\@deepseek-ai\dsh-desktop\logs\crash-*.log):

source: host
phase: startup
app: @deepseek-ai/dsh-desktop 0.2.1-rc.3
platform: win32 x64
electron: 44.7.0
node: 24.21.0

--- error ---
Error: desktop welcome: Web authentication failed
    at connectDesktopWelcome (.../resources/app.asar/lib/main.js:8886:31)
    at async Object.start (.../resources/app.asar/lib/main.js:12195:22)
    at async file:///.../resources/app.asar/lib/main.js:7162:5
    at async file:///.../resources/app.asar/lib/main.js:12313:4

Cookie jar at failure: 71 rows, all host_key = 127.0.0.1, path = /, HttpOnly, SameSite=Strict, 30-day Max-Age; names dsh-auth-<base64url(sha256("127.0.0.1:<port>"))>; 173-byte values; combined Cookie header 16,188 bytes.

Timeline (UTC+8, same machine, consecutive launches):

Time	Event
17:16:24	70th cookie stored; this launch completed normally (no crash log)
17:38:10.555	GET /?token=... answered 303 + Set-Cookie for the 71st cookie
17:38:10.967	welcome fetch aborts; crash log written
17:39–17:43	every retry fails immediately and writes no new cookie (the jar is already over the limit)

Root cause

1. BrowserAuth.authenticatedUrl() appends the process launch token to the host origin. GET /?token=... answers 303 See Other with set-cookie: dsh-auth-<hash(authority)> (HttpOnly, SameSite=Strict, 30 days).
2. The main process exchanges that token twice: Node fetch (no cookie jar) inside authenticateWebHost, then Electron net.fetch inside connectDesktopWelcome, which sends every cookie of the default session and follows the redirect to /.
3. The host binds --port 0, so the cookie name changes on every launch, and nothing prunes the previous rows. Chromium sends every 127.0.0.1 cookie regardless of port.
4. The host's web server calls createServer(listener) without maxHeaderSize, so Node's 16,384-byte default applies. Once the header block crosses it, the host answers 431 Request Header Fields Too Large before the index/auth route runs.

Byte accounting: one cookie is ~227 bytes. 70 cookies = 15,960 bytes (launch still worked); 71 cookies = 16,188 bytes, plus request line/UA/Host ≈ 16.5 KB > 16,384 bytes. We reproduced the threshold with a bare Node 24 http server: a 16,300-byte Cookie header is accepted, 16,400 bytes returns 431. The shell does not log the raw status, so this step is inferred from the byte count and matches the netlog posted in #9924.

What it is not

• Not third-party plugins: after the built-in "Disable third-party plugins..." action wrote an empty cordis.patch.yml ([]), four consecutive launches failed identically.
• Not the proxy/network: the Node first hop to the same URL succeeds; only the Chromium hop fails, and loopback bypasses the system proxy.
• Not account/credentials: dsh web on the same machine starts and authenticates normally.
• Not a corrupted profile: deleting only the 71 dsh-auth-* rows restores startup, and PRAGMA integrity_check reports ok.

Recovery (user side)

With the app closed, open %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies and run:

DELETE FROM cookies WHERE host_key = '127.0.0.1' AND name LIKE 'dsh-auth-%';

The next launch mints one fresh cookie and starts. The jar then grows again by one row per launch, so the failure returns after ~70 launches; 30-day expiry does not prevent it.

Suggested fix

1. Prune on startup: delete dsh-auth-* cookies for the current authority before minting a new one (only the current process's cookie is ever used).
2. Make the cookie name independent of the random port, or bind a stable port, so a new launch overwrites the previous cookie instead of adding one.
3. Defense in depth: create the listener with createServer({ maxHeaderSize: 64 * 1024 }, listener), and surface the real status (431/401) in the welcome failure message.
4. Clear the shell-owned default-session cookies on quit.

Related

The same failure has already been reported in #9924 (with netlog evidence), #10809, #10988, #11095, #11148, #11160, #11163 and others. This post adds an independent Windows rc.3 timeline with the exact 70→71 boundary; no maintainer response is visible on the earlier threads yet.

Request

Please consider pruning the per-launch auth cookies (or stabilizing the cookie name) in the desktop shell / client-connection. Full crash logs and cookie rows can be attached if useful.