[Desktop] 0.2.2-rc.1 ships without 93bef27 — dsh-auth-* cookie accumulation still kills startup at HTTP 431

[xuyahang]

TL;DR

The dsh-auth-* cookie accumulation that kills desktop startup is already fixed on main by 93bef27 (fix(desktop): remove legacy Host auth cookies from the default session, 2026-10-31), but that commit is not shipped in 0.2.2-rc.1 (2026-11-04), which is still the newest release. Every report of this bug on the current build is therefore expected behaviour, not a new regression — and no amount of user-side cleanup will make it stop recurring until a build containing that commit is published.

This post is not another symptom report. It is the release-gap evidence, plus a request to ship the fix — or, if it must wait, to ship the self-healing fallback so the failure stops being fatal.

Environment

Item	Value
OS	Windows 11 10.0.26200
Desktop build	0.2.2-rc.1 (desktop-runtime.json → nodeVersion: 24.21.0)
Install path	%LOCALAPPDATA%\Programs\DeepSeek Harness
Newer release available?	No. GET /releases ends at dsh-v0.2.2-rc.1, published 2026-11-04

Evidence that the fix is not in the release

1. GET /repos/deepseek-ai/deepseek-harness/compare/93bef27...dsh-v0.2.2-rc.1 returns status: diverged, ahead_by: 74, behind_by: 2 — the release branch is missing two commits that are on the fix's history.
2. String search inside the installed archive:

findstr /C:"removeLegacyHostCookies" "%LOCALAPPDATA%\Programs\DeepSeek Harness\resources\app.asar"
  → no match
findstr /C:"legacy Host cookie cleanup failed" ...\resources\app.asar
  → no match
findstr /C:"desktop welcome: Web authentication failed" ...\resources\app.asar
  → match   (control: the search works, the archive is readable)

removeLegacyHostCookies is the function introduced by 93bef27 in apps/desktop/src/web-document.ts, together with the call site in apps/desktop/src/main.ts and the log line desktop: legacy Host cookie cleanup failed. None of the three strings exist in the packaged app.asar, so the shipped desktop code predates the fix.

What the user sees

应用无法启动或已意外停止。
desktop welcome: Web authentication failed

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

"重启" and "禁用第三方插件、备份 profile patch 并重启" both fail, because the failure happens before any plugin loads.

Measured numbers on 0.2.2-rc.1

Observation	Value
dsh-auth-* rows in %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies at crash	71, all host_key=127.0.0.1
Sum of name+value length	16,117 bytes
First cookie created	2026-11-04T06:22:24Z (first launch of rc.1)
Last cookie created	2026-11-11T08:29:35Z (the launch that crashed)
Replayed request header, 71 cookies (16,044 B)	401
Replayed request header, 72 cookies (16,270 B)	431 Request Header Fields Too Large

The breaking point is Node's default maxHeaderSize = 16384, one cookie before the parser refuses the header. About ten launches a day for a week reaches it.

Why "restart / disable plugins" cannot help

cookieName(authority) hashes host:port. The desktop host picks a random loopback port on every launch (--port 0), so each launch mints a new cookie name; Chromium keys cookies by host, not port, so none of the previous names is ever replaced or expired, and every request carries all of them. Once the Cookie header crosses 16 KiB the request dies in the HTTP parser, before any application code runs.

Why 93bef27 fixes it, and what it does not cover

removeLegacyHostCookies walks session.defaultSession.cookies.get({ url: origin }) and removes every name starting with dsh-auth- for that hostname — including the ones minted by earlier launches. That is exactly the missing piece, and it is why shipping it matters more than any profile-level TTL workaround.

One gap remains for the web build: dsh web has no such cleanup, which is the subject of #12938. If the desktop fix ships but the web side does not, only half the reports stop.

Request

1. Publish a build that contains 93bef27 (0.2.2 final, or a new rc), and mention the cookie cleanup in the release notes so the many reporters under [Desktop][P0] Startup fails permanently after ~70 launches: dsh-auth-* cookies exceed Node's 16 KB header limit → HTTP 431, reported as "Web authentication failed" #12860 / Desktop startup dies after ~70 launches: stale dsh-auth-* cookies overflow Node's 16KB header limit (HTTP 431) #12586 / Desktop startup fails with "Web authentication failed": stale dsh-auth cookies accumulate until HTTP 431 #12377 / Desktop: dsh-auth-* cookies accumulate on every launch and eventually overflow the request-header limit (0.2.1-rc.5) #12013 / Issue: Desktop startup fails with desktop welcome: Web authentication failed after stale dsh-auth-* cookies exceed the 16 KB header limit (HTTP 431) #12606 know to upgrade.
2. If the cleanup cannot ship in a patch release, please add the two safety nets so the failure self-heals instead of bricking the launcher:
   • in the ?token exchange response, expire every other dsh-auth-* name seen in the request's Cookie header (Max-Age=0);
   • pass --max-http-header-size to the host process so a future naming change cannot hard-fail the shell again.
3. Document the interim workaround in the release notes. Today the only reliable recovery is manual, and most users never find it.

Interim workaround (verified on this machine)

Close DSH completely (including the tray), then delete:

%APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies
%APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies-journal

The jar is rebuilt on next launch. On 0.2.2-rc.1 this buys roughly another 70 launches.

To stop the recurrence until a fixed build ships, cap the cookie lifetime from the profile instead of the archive (this is a documented connection config field, so it survives app updates):

# ~/.dsh/profiles/desktop/cordis.patch.yml
- id: connection
  name: "@deepseek-ai/dsh-client-connection"
  config:
    trustedHosts: !!js ctx.webStartup.trustedHosts   # config is replaced wholesale, not deep-merged
    cookieMaxAgeDays: 3

Three days holds at most ~30 rows (~6.8 KB, 42% of the limit) at ten launches a day, versus ~70 rows (~15.9 KB, 97% of the limit) at the default 30 days.

Related threads

• [Desktop][P0] Startup fails permanently after ~70 launches: dsh-auth-* cookies exceed Node's 16 KB header limit → HTTP 431, reported as "Web authentication failed" #12860 — same failure, 0.2.2-rc.1, no reply yet
• Desktop startup dies after ~70 launches: stale dsh-auth-* cookies overflow Node's 16KB header limit (HTTP 431) #12586, Desktop startup fails with "Web authentication failed": stale dsh-auth cookies accumulate until HTTP 431 #12377, Desktop: dsh-auth-* cookies accumulate on every launch and eventually overflow the request-header limit (0.2.1-rc.5) #12013, Issue: Desktop startup fails with desktop welcome: Web authentication failed after stale dsh-auth-* cookies exceed the 16 KB header limit (HTTP 431) #12606 — same accumulation, different builds
• [Web] Stale dsh-auth-* cookies: server-side self-healing (retire other authorities cookies at mint time) #12938 — proposes server-side self-healing for the web build (the half 93bef27 does not cover)
• desktop: stale dsh-auth-* cookies overflow Node maxHeaderSize (16384) and break startup auth #11095 — earliest variant, including the 16 KiB analysis

Submitted through Discussions per the repository README (Issues are disabled).

[chuyu0629]

The release-gap evidence here is solid, and it matches what I see on Windows with 0.2.2-rc.1: desktop welcome: Web authentication failed after a few dozen launches, with the cookie DB packed with dsh-auth-* entries for 127.0.0.1.

One addition to the "so what do I do today" half: user-side cleanup is one rename away and keeps the old directory for rollback —

Rename-Item "$env:APPDATA\@deepseek-ai\dsh-desktop" "dsh-desktop.bak-$(Get-Date -f yyyyMMdd-HHmm)"

That resets the cookie jar without touching %USERPROFILE%\.dsh (sessions, profiles, plugins). It buys one cycle of launches, not a fix — as you say, only a build with the commit ends the recurrence.

For anyone who hits this repeatedly and doesn't want to remember the path, I packaged the check-and-reset (plus ~25 other startup failure classes, all backed up and reversible) into an MIT tool: #13243