Startup fails with "desktop welcome: Web authentication failed" after ~68 launches: loopback auth cookies accumulate past the 16 KB header limit (HTTP 431)

[dhdkfkfkf]

Environment

• @deepseek-ai/dsh-desktop 0.2.1-rc.2, Electron 44.7.0, Node 24.21.0, Windows 10.0.22631 (x64)
• Cookie store: %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies
• Host server: node:http createServer(listener) inside @deepseek-ai/dsh-host-webserver

Symptom

The desktop app cannot start. Every attempt exits during startup with:

Error: desktop welcome: Web authentication failed
    at connectDesktopWelcome (…\resources\app.asar\lib\main.js:8886:31)
    at async Object.start (…\lib\main.js:12195:22)

Four identical crash logs within one minute (2026-10-27 19:25–19:26 UTC). The "Disable third-party plugins, back up profile patch, and restart" safe mode does not help — dsh.profile.bundles was already reduced to @deepseek-ai/dsh-base + @deepseek-ai/dsh-web-app and cordis.patch.yml emptied, and startup still failed the same way.

Root cause (verified)

1. On each launch the host mints a persistent loopback cookie whose name encodes the authority, including the ephemeral port:

   dsh-auth-<base64url(sha256(authority))>   ; SameSite=Strict; HttpOnly; Path=/; Max-Age=…; Expires=…
   dsh-client-connection: TOKEN_QUERY="token", COOKIE_PREFIX="dsh-auth-"
   

2. That cookie is stored with a host-only scope (127.0.0.1). Cookie scope is port-agnostic, so a cookie minted for port 59909 is also sent to the next launch's port 60123 — while its name is unique to the old port. Nothing ever removes the previous ones.

3. The host creates its HTTP server with no options (createServer(listener)), so it inherits Node's default maxHeaderSize of 16,384 B. Once the accumulated set pushes the header block past that, llhttp rejects the request with 431 and closes the connection.

4. Observed failure state: 71 dsh-auth-* cookies for 127.0.0.1, ~225 B each (name+value), 15,975 B total → Cookie: header 16,186 B. Together with the request line and a normal navigation header set the block exceeds 16,384 B.

5. connectDesktopWelcome uses Electron's net.fetch, which attaches the browser cookie jar, so it receives the 431 and reports it as Web authentication failed. The Node-side handshake (authenticateWebHost, plain fetch, no cookie jar) still succeeds — which is why the host looks healthy when probed directly and why the log only blames authentication.

Evidence

• Replaying the exact persisted jar (all 71 cookies read from the Cookies DB) with normal browser headers against a freshly started host: 431, empty body.
• Same request with a single cookie: 200. With no cookie: 401. With the token URL: 303 Location: ./ + Set-Cookie, then 200 with the returned cookie — server and auth logic are fine.
• Cookie creation times, one per launch: 2026-10-24 → 12, 10-25 → 22, 10-26 → 19, 10-27 → 18 (71 total).
• Last successful boot 19:24:56Z; first failing boot 19:25:12Z — consistent with crossing the 16 KB line.

Minimal repro

Start the app (or the host process), read the loopback base URL from the host's ready IPC message, then send one request with a 16.4 KB Cookie header:

const cookies = Array.from({ length: 71 }, (_, i) => `dsh-auth-${i}=${"x".repeat(215)}`).join("; ");
const res = await fetch(new URL("./", readyUrl), { headers: { cookie: cookies } });
console.log(res.status); // 431, empty body

Any accumulated jar of that size reproduces it; ~68 real launches do it naturally (random port per launch).

Suggested fixes

1. Root fix — make the cookie name port-independent. Scope is host-only, so the name must be too: derive it from the host (or use a fixed name) so each launch overwrites the previous cookie instead of adding one next to it.
2. Or expire the old ones at startup — before minting, Set-Cookie … Max-Age=0 for the loopback host's dsh-auth-* names.
3. Or make it a session cookie (drop Max-Age/Expires), consistent with the per-activation signing secret; Chromium then discards it on exit.
4. Defensive: pass an explicit maxHeaderSize to createServer, and map 431 to an error that names the actual cause instead of "Web authentication failed".

User workaround (documented, local-only)

With the app closed, delete the loopback auth cookies:

sqlite3 "%APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies" \
  "delete from cookies where host_key='127.0.0.1' and name like 'dsh-auth-%';"

This touches only DSH's own loopback session cookies (re-minted on every launch); it does not affect any account/session cookies for other origins, and the app starts normally afterwards.

Impact

Hard startup failure with no in-app recovery path, the built-in safe mode cannot fix it, and the reported error misattributes the cause to authentication/credentials.

---

---

摘要（中文）

现象：桌面端启动即退出，日志只报 desktop welcome: Web authentication failed；安全模式同样失败。

原因：宿主每次启动给 127.0.0.1 签发一条永久 dsh-auth-<hash(host:port)> cookie。cookie 的作用域不含端口，但名字含端口，于是每次随机端口启动都会新增一条、旧的永不清理。累计约 68 条后，Cookie 头超过宿主 node:http 默认 16,384 B 的 maxHeaderSize，被 431 拒绝；Electron 的 net.fetch 拿到非 2xx，就报成了"认证失败"。Node 侧握手（无 cookie 罐）仍然成功，所以直接探测宿主一切正常。

证据：71 条 cookie、15,975 B，Cookie 头 16,186 B；把库里这 71 条原文配正常浏览器头重放到新起的宿主 → 431（空 body），只带一条 → 200，不带 → 401。创建时间一天 12–22 条，与启动次数一致。

建议：cookie 名改为只含 host（或固定名），每次启动覆盖而非新增；或启动时先让旧 cookie 过期；或改为会话 cookie；并给 createServer 显式设 maxHeaderSize、把 431 映射成能说明原因的错误。

用户侧绕行：关闭应用后删除 host_key='127.0.0.1' 的 dsh-auth-* 行，只影响 DSH 自己的回环会话 cookie，不动其他站点的账号 cookie。