Desktop auth cookie grows one row per launch and blocks startup with HTTP 431 after ~70 launches (still present in 0.2.1-rc.3)

[seashot]

Desktop auth cookie accumulates one entry per launch and eventually blocks startup with HTTP 431

Environment

• DSH Desktop 0.2.1-rc.2 (upgraded to 0.2.1-rc.3, see below: not fixed)
• Windows 11 x64, Electron 44.7.0, Node 24.21.0
• Default profile, local listener on http://127.0.0.1:<random port>

Summary

The browser-session cookie is named after the request authority, and the authority includes the ephemeral port. The cookie jar is keyed by host only, so every launch mints a new cookie that is never removed. Because all cookies for 127.0.0.1 are sent on every request, the Cookie header grows without bound until it exceeds Node's default 16 KiB header limit. The Host then answers 431, and the desktop shell reports only desktop welcome: Web authentication failed.

Root cause

@deepseek-ai/dsh-client-connection, browser-auth:

const COOKIE_PREFIX = "dsh-auth-";

// authority is host + port for HTTP listeners
function requestAudience(headers, secure) {
  const host = header(headers, "host");
  if (host === void 0) return void 0;
  const url = new URL(`${secure ? "https:" : "http:"}//${host}`);
  return secure ? url.origin : url.host;   // includes :port
}

function cookieName(authority) {
  return COOKIE_PREFIX + encodeBase64Url(createHash("sha256").update(authority).digest());
}

Each launch allocates a new port, so cookieName() differs, Set-Cookie adds a new row, and nothing ever deletes the previous rows. Cookies carry Max-Age of cookieMaxAgeDays (default 30 days, documented), which is far longer than the ~70 launches needed to hit the limit.

Measured boundary

Each cookie is 52-byte name + 173-byte value, i.e. 228 bytes with = and ; . Replaying the cookies captured from a real profile against the running listener:

cookies	request bytes	response
69	16,375	401 (reaches auth code)
70	16,603	431 Request Header Fields Too Large
71	16,831	431

Node's default maxHeaderSize is 16,384. The threshold is 70 cookies, i.e. 70 launches inside the 30-day window. At ~7 launches/day this reproduces in about 10 days. In the reported profile the jar held 71 cookies dated over 10 days.

Impact

• After the threshold is crossed, the app cannot start at all, every time, until the Chromium cookie DB is edited manually. There is no in-app path out.
• The error surfaced to the user says "The application could not start or stopped unexpectedly" and "If application files are missing or damaged, close the application and reinstall it" — which points at plugin corruption or a broken install, not at an oversized header. Reinstalling does not clear the profile, so it does not help.
• The offered recovery action ("Disable third-party plugins, back up profile patch, and restart") rewrites the user's cordis.patch.yml to an empty array in order to "rule out plugins". That is a heavy, wrong-path remedy for a header-size problem.

Confirmed still present in 0.2.1-rc.3

The same cookieName() / requestAudience() pair ships unchanged in the rc.3 app.asar; upgrading does not fix it. A profile that hit the limit on rc.2 reaches it again on rc.3.

Suggested fixes (any one is sufficient)

1. Derive the cookie name from the host only, not the authority, so a restart reuses the same row:

   function cookieName(authority) {
     const { hostname } = new URL(`http://${authority}`);
     return COOKIE_PREFIX + encodeBase64Url(createHash("sha256").update(hostname).digest());
   }

   Port binding can stay in the signed payload and be re-checked on read.
2. On Connection activation, enumerate session.cookies for the loopback host and delete every dsh-auth-* entry whose signed authority is not the current one (or keep only the newest N). Electron can do this before the first request.
3. If 1 and 2 are both unwanted, give the local listener an explicit, larger maxHeaderSize, and cap the number of minted cookies.
4. Independently of the fix: include the HTTP status in the error. 431 versus 401 would have made this diagnosable in one minute instead of an afternoon.

Reproduction without a full app

With the app closed, read %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies (SQLite, table cookies, host_key = '127.0.0.1', name LIKE 'dsh-auth-%'), join name=value with ; into a Cookie header, send it to the listener alongside a normal Chromium header set, and vary the number of pairs. 69 passes, 70 returns 431.

---

Related defect, same incident: the recovery action backs up the post-overwrite state

"Disable third-party plugins, back up profile patch, and restart" writes the patch file and then creates the .bak. On a real machine, both cordis.patch.yml.bak-<id> and cordis.patch.yml.minimal-<stamp> contained the already-emptied [] (217 bytes), not the 3,793-byte original. The original only survived because an older rotating backup happened to exist. A recovery action whose label promises a backup should copy the file before rewriting it.

---

中文摘要

桌面端每次启动都会为 127.0.0.1:<随机端口> 新发一个 dsh-auth-<sha256(host:port)> cookie，旧的从不清理；Chromium 只按主机名保存，于是每次启动 Cookie 头都会增长。实测 69 条返回 401、70 条返回 431（Node 默认 16 KiB 上限），约 70 次启动后应用彻底起不来，界面只报 "Web authentication failed"，并引导用户重装或禁用插件。rc.3 中这段代码未改。建议：cookie 名只按主机名计算，或启动时清理不匹配当前 authority 的旧 cookie，或给本地监听器放大 maxHeaderSize；另外把真实状态码带进错误信息。附带一处：恢复按钮的"备份"是在覆盖之后做的，备份到的是清空后的版本。

[PerseusNana7mi]

Additional confirmation from a Windows x64 installation of DSH Desktop 0.2.1-rc.3 (Electron 44.7.0, Node 24.21.0).

The observed startup failure was:

source: host
phase: startup
Error: desktop welcome: Web authentication failed
    at connectDesktopWelcome (.../resources/app.asar/lib/main.js:8886:31)

What was verified during troubleshooting:

• Repeated restarts failed, including after using “Disable third-party plugins, back up profile patch, and restart”. The active profile patch had become an empty array, but the same startup failure persisted.
• A Chromium network log captured the actual local response: HTTP/1.1 431 Request Header Fields Too Large. The request included many loopback cookies.
• The Desktop Chromium cookie database contained 71 cookies, all for 127.0.0.1, matching the dsh% name filter. Inspection of the bundled connection code also confirmed that the cookie name hashes the request authority (including the port).
• With DSH fully stopped, the cookie database was backed up, then only those DSH loopback cookie rows were removed. DSH subsequently started successfully and opened an existing conversation window, without reinstalling or modifying the application bundle, or deleting conversation/task data.

This confirms that clearing the accumulated cookies is an effective recovery step for this failure, but it is only a workaround: the installed cookie-management code remains unchanged.

For a durable fix, please bound/clean up stale Desktop-owned loopback auth cookies before the first authenticated request, while preserving isolation for concurrently running instances. Also include the actual HTTP status in the startup error, so a 431 does not send users down the plugin-reset/reinstall path.

中文补充：本机 rc.3 确认遇到同一问题，71 条本机 Cookie 导致 HTTP 431；禁用第三方插件后仍失败。退出 DSH、备份并清理这些 Cookie 后，原有会话窗口可正常打开。希望启动前处理旧认证 Cookie 的积累，并在报错中显示真实 HTTP 状态码。

[TurnX-alt]

Third independent confirmation on 0.2.1-rc.3 / Windows x64, plus an A/B experiment on a real installation that isolates the cookie jar as the sole cause.

Environment

• DSH Desktop 0.2.1-rc.3 (dshBuildCommit be72761), Windows x64, Electron 44.7.0, Node 24.21.0
• Crash signature identical to the reports above: crash-…-host.log, phase: startup, Error: desktop welcome: Web authentication failed at connectDesktopWelcome (main.js:8886)

State of the jar when the crash loop started

Read from %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies while the app was closed:

• 71 dsh-auth-* rows, all host_key = '127.0.0.1', SUM(length(name)+length(value)+2) = 16,257 bytes — the Cookie header alone before any other request headers
• Per-day minting of those 71 rows: 10-20: 3 · 10-22: 34 · 10-23: 20 · 10-24: 3 · 10-25: 2 · 10-26: 9. Roughly matches the ~70-launch threshold estimated in the original report.
• The app started successfully three times that day (cookies minted 18:32, 18:47, 19:04), then entered the crash loop at 19:15 — three crashes in 23 seconds, one more cookie minted by the first crashing run before it died (visible as the 19:15:45 creation row).

A/B experiment on the real installer

With the app fully stopped, rows were inserted into / deleted from the cookies table directly (SQLite). No other state was touched.

phase	jar contents	outcome
A: injected 85 synthetic dsh-auth-* rows (jar: 86 rows, ~17.3 KB)	launch → crash within seconds, crash-2026-10-26T19-48-43-host.log with the exact same signature as the spontaneous crashes	reproduced
B: deleted all dsh-auth-* loopback rows	launch → healthy startup, app alive 90 s+, closed cleanly, no crash log; exactly 1 fresh dsh-auth-* row minted at first launch	recovered

This removes the remaining alternative explanations (plugin composition, profile state, rc.3 packaging): the jar contents alone flip the same installation between "cannot start" and "starts fine".

Self-reinforcing loop

Phase A also re-confirmed the loop the original report implies: the crashing run mints one more real cookie during the successful first hop (authenticateWebHost uses Node fetch without cookies and always succeeds), so every failed restart grows the jar. A profile past the threshold never recovers by restarting — including via "Disable third-party plugins, back up profile patch, and restart", which was also observed to strip the profile's bundle list without helping.

Both suggested directions (name cookies by host, or prune stale dsh-auth-* rows before the first authenticated request) would have prevented this instance; surfacing the HTTP status in the error would have cut diagnosis to minutes.

中文补充:rc.3 真机 A/B 验证。注入 85 条合成 dsh-auth-* cookie(共 86 条 ≈17.3 KB)后启动即崩,crash log 与自发崩溃逐字一致;清空后启动正常、正常退出,并新铸 1 条 cookie。崩溃那次运行在死前又 mint 了 1 条真 cookie——每崩一次 jar 更大,重启无法自愈,「禁用第三方插件」按钮也无济于事(它会剥掉 profile bundles 但不解决问题)。清理 jar 内 dsh-auth-* 行即可恢复,与楼上确认一致。

[sdusry]

Additional confirmation on macOS arm64, DSH Desktop 0.2.1-rc.3, Electron 44.7.0, Node 24.21.0.

The startup error was:

Error: desktop welcome: Web authentication failed
    at connectDesktopWelcome (.../app.asar/lib/main.js:8886:31)

What we verified locally:

• The Desktop cookie database contained 71 unexpired, unpartitioned dsh-auth-* cookies, all for 127.0.0.1 with Path=/.
• Each name was 52 bytes and each value 173 bytes. The joined Cookie header value was 16,186 bytes, before ordinary request headers.
• A local Node HTTP reproduction using only synthetic cookies of those lengths, plus ordinary headers, returned HTTP 431 before the request handler was reached. With one same-length cookie, the handler was reached and returned 200. This synthetic reproduction ran on Node 20.19.2; the affected Desktop's embedded Node is 24.21.0. The original Desktop log did not retain the HTTP status, so this is not presented as a captured Desktop network response.

Recovery confirmed on the actual installation: ordinary restarts, rolling back a custom Chrome bridge, and the built-in “Disable third-party plugins, back up profile patch, and restart” action all failed to restore startup. After fully exiting DSH, privately backing up its Cookie database, and deleting only those 71 DSH-owned loopback auth rows, the same installed application opened its normal main window and existing conversations again. We did not reinstall or modify the application bundle, or delete conversation/model-key data.

Another focused fix option: Desktop already obtains the current Host cookie via authenticateWebHost. The native welcome HTTP transport and account sockets can reuse that single owned Host cookie through the existing authenticated forwarder, rather than attaching the entire Chromium cookie jar. This preserves authority/port-bound authentication. Also include the HTTP status in the startup error so that 431 is distinguishable from 401.

A local source change for this transport wiring and status reporting passed 133 focused Desktop tests and the Desktop Host typecheck; it has not been submitted upstream or deployed to the installed app. No real cookie values, credentials, or private diagnostic paths are included here.