Startup fails with "Web authentication failed": local dsh-auth-* cookies accumulate on every restart until the request header limit is exceeded (win32, 0.2.1-rc.2)

[ljzwdsj]

Environment: Windows 11 (win32 x64) · @deepseek-ai/dsh-desktop 0.2.1-rc.2 · Electron 44.7.0 · Node 24.21.0

1. Background

• Installed the DeepSeek desktop app on Oct 18 and used it daily with 2–3 restarts per day (71 launches in ~4 days)
• About one day after installing, I wrote my own desktop-pet plugin (dsh-whale-pet) — pure UI decoration and voice playback, nothing related to auth, cookies, or networking. Plugin debugging involved a lot of restarts
• On the evening of Oct 22, the app suddenly failed to start: the process appeared and exited four times in a row, each time with Web authentication failed

2. The issue I'd like to report

Crash log logs/crash-2026-10-22T14-35-51-369Z-host.log:

source: host
phase: startup
app: @deepseek-ai/dsh-desktop 0.2.1-rc.2
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 (…/lib/main.js:12195:22)
    at async …/lib/main.js:7162:5
    at async …/lib/main.js:12313:4

While investigating, I found that 71 dsh-auth-* cookies had accumulated under 127.0.0.1. The Cookie request header alone is 16,186 bytes (per cookie: 52-char name + = + 173-byte value = 226 B, plus a 2-byte ; separator between entries, i.e. 71×226 + 70×2). Add the usual Host, User-Agent and other headers, and the total necessarily exceeds Node.js's default 16,384-byte header limit (maxHeaderSize).

The issue: the cookie count grows by exactly 1 on every restart, and I suspect that once the header crosses the limit, startup authentication fails. To confirm, I ran three sets of verification.

3. Verification

Check 1: each launch adds one cookie, and old ones are never removed

• The 71 cookie names follow dsh-auth- + base64url(sha256(authority)), where authority contains the random listening port
• Brute-forcing 127.0.0.1:1024–65535 mapped all 71 records to 71 distinct ports (range 49662–65534, the Windows dynamic port range)
• So: one launch = one new record. Since the port changes every time, the cookie name changes too, so records can never overwrite each other; and I saw no sign of old records being deleted
• All records had expires set to 30 days after creation, so none would naturally expire during Oct 18–22
• Common suspects were ruled out along the way: no system proxy (ProxyEnable=0); credentials intact (after clearing the cookies the app started without re-login); no port conflict; authenticateWebHost had already passed — the failure happened on the subsequent welcome connection

Check 2: forced over-limit reproduction — push the cookies past the limit and it always crashes; roll back and it recovers

This is the most direct check. I ran an injection experiment on a copy of the app's Cookies database (the app itself was not modified):

Stage	dsh-auth-* count	Cookie header size	Launch result
Before injection	2	454 B	✅ normal start
After injecting 120 format-identical rows	122	27,814 B	❌ crash on startup
After rolling Cookies back from backup	original state	—	✅ relaunched successfully

• The injected rows were synthesized to match the real cookies exactly: 52-char name, 173-byte plaintext value, empty encrypted_value, +30 days expiry
• The crash behavior was identical to the natural accumulation: crashDetected=true, one crash-*-host.log (phase: startup), zero renderer logs, 4 leftover processes
• The stack trace was word-for-word the same: desktop welcome: Web authentication failed at connectDesktopWelcome (main.js:8886:31)

This closes the causal loop: cookies over the limit → startup authentication failure.

Check 3: ruled out my own plugin (control experiment)

To rule out "my plugin broke the environment", I ran a control experiment:

• Removed the plugin from the profile completely before the experiment
• Launched the app 8 times in a row; each round: launch → wait for the main window to actually appear → close normally → count cookies (Chromium holds the DB exclusively while running, so counting had to happen after exit)
• 3 rounds were discarded as invalid (2 never really started; 1 closed too early, before the handshake reached the cookie-writing step). The remaining 5 valid launches each added exactly 1 cookie, monotonically increasing
• During the experiment the plugin was not loaded, and the leftover-process behavior was unchanged

Conclusion: with or without the plugin, the behavior is identical — this is not related to third-party plugins.

A related observation: closing the main window leaves 5 DeepSeek Harness processes behind. On the next launch the UI shows "no response / spinning forever" because control is handed to the windowless old instance — and every such retry also appears to add one more cookie.

4. Code I came across (for reference only)

In app.asar, lib/types/browser-auth.js (part of @deepseek-ai/dsh-desktop-host), the issuance logic looks like:

const COOKIE_PREFIX = "dsh-auth-";
const DAY_MILLISECONDS = 1440 * 60 * 1e3;   // 30 days

function cookieName(authority) {
    return COOKIE_PREFIX + encodeBase64Url(sha256(authority));
}

From what I could see, there is no logic that cleans up old cookies (neither expiry-by-authority nor a cap with recycling). I did not read the entire codebase, so this is only my observation and may be incomplete — sharing it in case it helps the team.

5. My current workaround

Since I still need to use the app, I wrote a small local guard script (dsh_cookie_guard.py) that watches for process exit and then deletes records matching host_key='127.0.0.1' AND name LIKE 'dsh-auth-%', with autostart, process patrol, and log rotation.

This is only a stopgap so I can keep working — it doesn't modify the app, and I understand it is not a real fix. Long term, I'd hope the issuance/cleanup strategy could be revisited on the official side.

6. A few rough ideas (just brainstorming, take or leave)

1. On startup, delete historical records that don't match the current authority
2. Persist the host service port, so a fixed port means a fixed cookie name and same-name overwrite
3. Make the cookie a session cookie (expires with the session)
4. Add a cap that recycles the oldest records beyond a threshold
5. Ensure child processes fully exit when the main window closes, so leftover processes can't hold the single-instance lock

7. How to reproduce / check, and evidence

-- current accumulated count
SELECT COUNT(*) FROM cookies
WHERE host_key='127.0.0.1' AND name LIKE 'dsh-auth-%';

-- estimate cookie header size (226 B per cookie + 2 B between entries)
SELECT SUM(LENGTH(name) + LENGTH(value) + 1) + (COUNT(*) - 1) * 2 AS header_bytes,
       COUNT(*) AS cnt
FROM cookies
WHERE host_key='127.0.0.1' AND name LIKE 'dsh-auth-%';

DB path: %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies (if the header size is already over the limit, fully quit the app first — otherwise the file is locked).

Evidence package (sanitized, safe to share): dsh-cookie-repro-20261023-redacted.zip

• Contains: before/after Cookies DB snapshots (real values replaced with 173-byte dummies; names, counts and header sizes preserved), crash logs, and a machine-readable repro-result.json
  dsh-cookie-repro-20261023-redacted.zip

• SHA256: 00aeecda666c951a85061e09817da76b81e4b4a13c0fc3cec1c6e6b6e245acb2

• Happy to attach it or send it by email if further investigation needs it (no credentials included)

[ljzwdsj]

A few clarifications on my own report, so nobody has to chase them.

1) About the launch count. The "2–3 restarts per day" line describes my normal usage. The 71 launches accumulated because during those days I was developing and debugging a desktop-pet plugin for myself, which meant dozens of extra start/quit cycles on top of daily use — a plugin developer's restart pattern, not a typical user's. The plugin itself is irrelevant to the bug: check 3 removed it from the profile entirely and 5 valid launches still added exactly 5 cookies.

2) Header arithmetic, written out. So the number can be checked instead of guessed:

52 (name) + 1 ("=") + 173 (value) = 226 B per entry
71 × 226 + 70 × 2 ("; " between entries, none after the last one) = 16,186 B

That budget also has to carry Host, User-Agent and the rest, which is why the full header crosses Node's 16,384-byte default even though the Cookie portion alone is close.

3) Scope of the injection test. It was done on a copy of the Cookies database — the real one was never modified. The crash reproduced identically (same stack, same single phase: startup log, same 4 leftover processes), and rolling the copy back made startup work again. The snapshots in the evidence zip have real values replaced with 173-byte dummies; names, counts, expires and header sizes are unchanged, and no credentials are included.

Minimal reproduction for anyone who wants to confirm it:

1. Launch the app, let the main window appear, quit, repeat ~10 times.
2. With the app fully exited, run the count query in section 7 of the original post — it grows by exactly one per launch.
3. Push the count past the limit (cleanest way: the injection described in check 2, on a copy) and launch — startup fails at connectDesktopWelcome.

The sanitized evidence package is already attached to the original post; happy to re-share it by email if that is more convenient.

[PerryLink]

Your arithmetic matches the header exactly. Seventy-one cookies at 226 bytes each, plus 70 two-byte separators, is 16,186 — and that only adds up if every launch wrote a different name.

The name is derived from the authority. packages/client/connection/src/browser-auth.ts:116-118:

function cookieName(authority: string): string {
  return COOKIE_PREFIX + encodeBase64Url(createHash('sha256').update(authority).digest())
}

and requestAudience (:78-88) returns url.host for http and url.origin for https (:84) — both keep a non-default port. So a launch that picked a new loopback port produces a new 52-character name (dsh-auth- plus 43 base64url characters). The cookie is written with Max-Age at :283 and :344 and never deleted (sessionCookie, :131-140), and a cookie for 127.0.0.1 is sent on every request to that host regardless of port — so the jar gains one entry per launch until the request header crosses maxHeaderSize and the Host answers 431.

That also explains the recovery pattern: clearing cookies for 127.0.0.1 fixes startup, and reinstalling the app does not, because the jar lives outside the install.

Fix shape, two halves. Make the name port-independent for loopback (hash the host, or use one fixed name and disambiguate inside the signed value), and on startup delete sibling dsh-auth-* cookies this launch's name does not match. The second half is not optional: a fix that only stops new accumulation leaves the affected users with 71 cookies and still unable to start.

[ljzwdsj]

Thanks for the detailed reply — and for taking the time to trace this down to cookieName / requestAudience. That's far clearer than what I was able to infer from the outside.

I've gone through both halves and I understand why both are needed: making the name port-independent for loopback addresses the cause, while deleting non-matching dsh-auth-* siblings on startup is what gets users who already have them starting again. The naming change is what stops this from recurring; the cleanup is the way back for anyone already affected.

On my side I'm running a local workaround in the meantime — a small watcher that clears the accumulated dsh-auth-* cookies after the app exits — which keeps startup working. It's only a stopgap, and I'd rather rely on the real fix than maintain it.

Thanks again for the thorough investigation and for following up here — I really appreciate the time you put into this.