dsh-desktop fails to start after ~70 launches: dsh-auth cookies accumulate per random port and overflow Node's 16 KiB request-header limit (431)

[longjiakai]

Environment

• OS: Windows 10 22H2 (10.0.19045), x64
• DSH desktop: 0.2.2-rc.1 — Electron 44.7.0, Node 24.21.0
• Profile: desktop, single machine, loopback only
• Shipped app.asar, no local patches to the shell

Symptom

After a few weeks of ordinary use the desktop app stopped starting. Every launch ends with:

Error: desktop welcome: Web authentication failed
    at connectDesktopWelcome (file:///D:/DeepSeek%20Harness/resources/app.asar/lib/main.js:16856:31)
    at async Object.start (file:///D:/DeepSeek%20Harness/resources/app.asar/lib/main.js:20386:22)

The host itself comes up and prints its line (dsh web: http://127.0.0.1:<random-port>/?token=…), then the desktop shell's welcome fetch never authenticates. %APPDATA%\@deepseek-ai\dsh-desktop\logs\crash-*-host.log has one entry per attempt (9 attempts in one morning, all identical). Restarting does not help; reinstalling does not help.

Root cause

1. BrowserAuth.authorizeIndex() mints the session cookie only on GET / carrying a valid ?token=, via sessionCookie(cookieName(authority), …), where authority is the request's host:port (requestAudience).
2. Chromium's cookie jar is keyed by host, not by authority, so every random port produces a new cookie name that never replaces an older one.
3. dsh-desktop always launches the host with a fixed argument list: --no-open --host 127.0.0.1 --port 0, so the port is different on every start.
4. cookieMaxAgeDays defaults to 30, so stale cookies survive a month.

Net effect: one dsh-auth-* cookie accumulates per launch, forever.

Evidence

Cookie DB at %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies (copied with the app closed):

• 71 rows, all host_key = 127.0.0.1, path = /
• all named dsh-auth-<43-char base64url> (52 bytes each)
• value is plaintext, 171–173 bytes, e.g. v1.eyJ2ZXJzaW9uIjoxLCJhdXRob3JpdHkiOiIxMjcuMC4wLjE6MTkzODci… → {"version":1,"authority":"127.0.0.1:19387",…}

Request-header cost: 71 × (52 + 171 + 3) = 16,076 bytes of Cookie alone.

Node's HTTP server defaults to maxHeaderSize = 16384 for the request line plus all headers, and Chromium adds roughly 400 B of Host / User-Agent / sec-ch-ua* / sec-fetch-* / Accept*. So the crossover lands at ~70 cookies: the next launch pushes the request over the limit, the server answers 431, net.fetch resolves with ok === false, and connectDesktopWelcome throws "Web authentication failed" — with no hint that the real cause is a header-size limit.

The obvious workaround has its own trap

connection.cookieMaxAgeDays can bound the accumulation (we currently run 1), but:

• the cookie uses an absolute expiry (issuedAt + maxAgeMilliseconds), not a sliding refresh;
• the only refresh path is the GET /?token= exchange, and after the 303 → ./ the token is no longer in the URL;
• ConnectionRecoveryConfigSchema only carries backoff timings (backoffBaseMs, backoffFactor, backoffMaxMs, generationReady*) — there is no re-authentication path.

So a long-running instance turns every /api call into 401 once the cookie expires, and only a restart recovers. 30 days is what causes the startup failure; 1 day kills long-lived sessions. Neither default is right for a desktop app.

Suggested fixes

1. Prune on mint (smallest change). When authorizeIndex mints a cookie, remove every other dsh-auth-* cookie for the same host through Electron's session.cookies.remove(). The jar stays at one entry per host and the authority binding is untouched.
2. Name by host only. The cookie already carries authority in its signed payload and isAuthenticated validates it. Deriving the name from the hostname alone (without the port) makes successive launches replace each other, so accumulation becomes structurally impossible.
3. Let the desktop reuse a stable port. --port 0 is hardcoded; a stable/reusable port would also remove the accumulation and make the GUI URL bookmarkable.
4. Re-mint on 401 / sliding refresh, so a desktop instance that stays open does not die at the cookie's max age. (Related: RPC 401s currently surface as a generic reconnect loop.)

Local recovery for anyone hitting this

Quit the desktop app, delete %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies, relaunch. On Linux/macOS the same jar lives in the @deepseek-ai/dsh-desktop user-data directory and the same random-port behaviour applies.

Happy to supply the raw cookie rows, the crash-*-host.log files, or the asar excerpts for authorizeIndex / sessionCookie / cookieName if that helps.

[longjiakai]

Thanks — and sorry, I should have searched before posting: this is already reported several times, e.g. #11215 (answered, same measurements) and #11397 (source-level check confirming it is still unfixed at f3803c96 / 0.2.2-alpha.2). Please treat this thread as a duplicate and consolidate wherever you prefer.

Two things this machine adds that I did not find in those threads:

1. A config-level mitigation that needs no code change. @deepseek-ai/dsh-client-connection accepts cookieMaxAgeDays, so the steady state becomes "launches in the last N days" instead of 30 days' worth:

- id: connection
  config:
    cookieMaxAgeDays: 1

• Measured before/after: 71 stale dsh-auth-* rows (16,076 B of Cookie header) → after clearing them, ~3 rows.
• Caveat, because I hit it: the cookie uses an absolute expiry and is only re-minted by the GET /?token= exchange. After the 303 → ./ the token is gone from the URL, and ConnectionRecoveryConfigSchema has no re-auth path — so an instance left open past the max age turns every /api call into 401 and only a restart recovers. For a desktop app 1 is too short; 3 is a reasonable middle ground, 7+ starts to collide with a debugging day of repeated restarts. This is a workaround, not a fix — the jar still mints one cookie per launch.

2. A second trap that deserves its own report. The startup-failure dialog's third button — "Disable third-party plugins, back up profile patch, and restart" — runs sanitizeProfile(), which renames cordis.patch.yml to .bak-<ms> and rewrites dsh.profile.bundles to ['@deepseek-ai/dsh-base', '@deepseek-ai/dsh-web-app']. Verified on disk here: three .bak-<ms> files whose millisecond suffixes decode to 08:42:14 / 08:42:20 / 08:42:26 local (12 s apart), while the last good config (2,786 B) still carries its original 01:56 mtime — renames preserve mtime, which is how the earlier state is recoverable at all.

The patch file is backed up. The bundle list is not: for a profile with ~35 plugins that is the destructive half of the operation, and it is not mentioned in the button label. Because a 431 makes this dialog appear on every launch, any user hitting this cookie bug is one click away from losing their bundle list. Suggestions: keep a copy of the previous bundles next to the patch .bak, and state in the button text that the bundle list is rewritten and will not come back on the next launch.

[TG-xian]

Thanks for the write-up — the root-cause chain matches exactly what I hit this morning on Windows, and I have a few measured numbers that your derivation doesn't cover, plus a cleanup script that others can reuse.

I'm posting this as a supplement, not a new report: I see this has been filed several times already (#12649, #12739, #12911), so everything below is meant to be additive.

Measured sizes (one machine, 71 historical cookies)

Where your analysis is code-derived, these are from the actual Chromium cookie DB (Network/Cookies, read with sqlite3 from a copy while the app was closed):

Quantity	Measured	Note
cookie rows under 127.0.0.1 with prefix dsh-auth-	71	one per historical port
name length	52 chars, constant	dsh-auth- (9) + 43 chars base64url(sha256)
value length	171–173 chars	varies by 2
one name=value; pair	225–227 B, mean 225.5 B
all 71 concatenated into one Cookie: header	16,011 B
same header + typical Chromium request headers	16,664 B	observed 431

So the budget math becomes concrete:

16,384 (Node's default max header size)
-   574 (user-agent / accept / sec-fetch-* observed on this machine)
= 15,810 B available for cookies
/ 225.5 B per cookie
= 70.1 cookies

That puts the threshold at the 70th cookie, which lines up with the "~70 launches" figures others reported — but now it's a number you can compute for any machine rather than estimate.

Caveat: 225.5 B is a mean over my 71 samples. It depends on the length of the payload/signature (the 171–173 spread above), so other installs will differ by a few bytes per cookie; the 574 B header estimate is also browser-version dependent. Treat the formula as the invariant, the constants as machine-specific.

What deletion looked like

Before / after, same DB, DELETE FROM cookies WHERE host_key='127.0.0.1' AND name LIKE 'dsh-auth-%' then VACUUM:

• 71 rows -> 0, DB file 53,248 B -> 20,480 B
• no other cookie touched (on my install every row in that DB happened to be dsh-auth-*; on a machine with other loopback cookies this filter matters)

Note the DB is exclusively locked while the desktop is running — copying it fails with WinError 32. Cleanup has to happen with the app fully closed.

Script, if useful to others

I wrote a small wrapper that does the same thing with guardrails:

powershell -File clean-auth-cookies.ps1 -WhatIf   # dry run: reports counts and header size, deletes nothing
powershell -File clean-auth-cookies.ps1           # backup, then delete, then VACUUM

Behaviour:

• refuses to run if the desktop process is alive or the DB cannot be opened with exclusive write access (rather than half-failing)
• backs up the whole Cookies file to Cookies.bak-<timestamp> before touching anything
• deletes only host_key='127.0.0.1' AND name LIKE 'dsh-auth-%', keeps the N most recently used (default 1), reports the resulting header budget
• -WhatIf prints the same numbers without writing

I can attach the file or open a PR with it under scripts/ if that's wanted — say the word and I'll do whichever is less work for you.

Not asking for a timeline

I'm not after an ETA. Since three separate reports converged on the same mechanism, I assume it's already on your radar; the only reason I'm commenting is that the measured constants above might save the next person some arithmetic. If it's already fixed in a build I haven't tried, feel free to ignore this.

[aturzone]

This report's root-cause chain matches master (fcc0ad4621), and the most useful missing fact is that the accumulation fix already exists — it is just not in the released desktop shell:

• packages/client/connection/src/browser-auth.ts:18,116-117 derives the cookie name from the full host:port authority (sha256(authority)), and packages/client/connection/src/index.ts:115 defaults cookieMaxAgeDays to 30, so one dsh-auth-* cookie per random Host port is expected behavior in that build.
• Upstream fixed it on 2026-10-31: 5868dbc357 ("stop storing Host auth cookies in the Electron session" — the welcome RPC client and account WebSocket now send the Cookie header returned by authentication explicitly, with no cookie jar) and 93bef27ec7 ("remove legacy Host auth cookies from the default session"; the prune is removeLegacyHostCookies in apps/desktop/src/web-document.ts:65-69, called from apps/desktop/src/main.ts:542).
• Ancestry check: both commits are ancestors of master (fcc0ad4621) but not of the release commit dsh-v0.2.2-rc.1 (66491b05e3, 2026-11-04). The release branch was cut before those fixes, so a desktop build from rc.1 still carries the old jar behavior. On the current build the workarounds above are the right move; on the next desktop build the accumulation should be structurally gone.

One residual gap is ordering, not accumulation: on master the legacy prune is fire-and-forget (void removeLegacyHostCookies(...) at main.ts:542). Our branch fix/desktop-cookie-cleanup-order (495f17a0e4) awaits it before boot continues and adds an ordering regression (with the old call, the welcome backend connects before the prune resolves). That is a hardening of the existing fix, not an alternative to it.

For the current build: quit fully (not just close the window), delete Network/Cookies under %APPDATA%\@deepseek-ai\dsh-desktop, relaunch. connection.cookieMaxAgeDays: 1 bounds regrowth but, as noted above, an absolute-expiry cookie in a long-running instance means 401s until restart.

If it reproduces after the next desktop release, two measurements close the loop: row count of dsh-auth-* in Network/Cookies, and whether crash-*-host.log shows 431 again.

[Forevery1]

@tianyicui