Desktop startup crash loop: Web authentication failed (0.2.2-rc.1)

[zhengshupei-dshhub]

Summary

DSH desktop 0.2.2-rc.1 crashed 5 times in a row at startup (2026-11-07 09:17:52–09:32:43 UTC+8). The crash dialog offered two buttons: "Restart" and "Disable third-party plugins". After the first crash I clicked "Disable third-party plugins"; the next 4 crashes still happened, so the issue is unrelated to third-party plugins.

Error

All 5 crash logs show the exact same stack:

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

The Electron main process starts a Desktop Host child, receives an authenticated ready.url (e.g. http://127.0.0.1:<port>/?token=...), then calls connectDesktopWelcome() with a net.fetch that is supposed to return 200 after following the 303 set-cookie redirect. During the crash window that request failed (returned non-2xx).

What I ruled out

Suspect	Evidence	Ruling
Profile config corruption	I copied the crash-time cordis.patch.yml (13 entries, 28931 bytes) into a separate test profile and booted it directly with the dsh-desktop-host entry. It reached dsh web: http://127.0.0.1:57023/?token=... and loaded all providers/models.	Not config
Third-party plugins	Clicked "Disable third-party plugins" after crash #1; crashes #2–#5 still happened with a minimal patch (agent-default-model + 3 ui entries).	Not plugins
System proxy / network	scutil --proxy showed all proxy modes disabled; Clash Verge had no active process.	Not proxy
Token single-use / expired	After the issue self-healed, the same token URL could be requested multiple times and returned 303 then 200.	Not a stale token
Host process dead	WorkBuddy and dsh-dafeiyu heartbeat files kept updating at 09:18–09:31, meaning the host was alive.	Host was running

The problem resolved only after a full process restart at 09:38 (new SingletonLock PID). It looks like an internal race in the desktop startup handshake between the Electron main process and the Desktop Host child.

Side effect: user patch got overwritten

After clicking "Disable third-party plugins", DSH rewrote cordis.patch.yml to an 828-byte minimal version containing only:

• agent-default-model
• ui-settings-account
• ui-chat
• ui-settings

All other configured entries (llm-pi-ai, model-router, dsh-connect-workbuddy, dsh-dafeiyu, permission, etc.) were silently dropped. Fortunately DSH had auto-backed up the previous patch as cordis.patch.yml.bak-<timestamp>, so I could restore it.

Requests

1. Make startup authentication more robust against transient races, or at least retry a few times before surfacing a fatal crash.
2. Do not silently overwrite cordis.patch.yml when the user clicks "Disable third-party plugins"; instead move third-party entries to disabled: true, or ask for confirmation.
3. Document/expose the automatic cordis.patch.yml.bak-* backups so users know they can restore after a crash.

Environment

• DSH: 0.2.2-rc.1
• Electron: 44.7.0
• Node: 24.21.0
• macOS: darwin arm64
• Profile: ~/.dsh/profiles/desktop
• Crash logs: ~/Library/Logs/DeepSeek Harness/crash-2026-11-07T01-1*.log

[cedricwyh]

Same crash here on macOS (Apple Silicon) with the officially notarized 0.2.2-rc.1 — and we isolated the root cause. The stack matches exactly (connectDesktopWelcome at app.asar/lib/main.js:16856, start at 20386).

Root cause

lib/main.js treats the welcome handshake's 303 redirect as a failure, and uses net.fetch, which does not carry SameSite=Strict cookies across the redirect, so the follow-up request 401s:

// ~16857
const authenticated = await send(authenticatedUrl, { credentials: "include" });
await authenticated.body?.cancel();
if (!authenticated.ok) throw new Error("desktop welcome: Web authentication failed");  // 303 is not ok -> throw

// ~20387
welcomeBackend = await connectDesktopWelcome(
  ready.url,
  (input, init) => net.fetch(input, init),                       // net.fetch drops SameSite cookie on 303
  async () => (await session.defaultSession.cookies.get({ url: ready.url }))
      .map(c => `${c.name}=${c.value}`).join("; ")
);

Because this throws very early inside start(), the rest of boot aborts — plugins that depend on credentials / connection never receive their services and the app never reaches ready. That is why "Disable third-party plugins" does not help: it is not a plugin problem, it is the main-process handshake aborting before plugins are wired.

Suggested fix

1. Treat 301/302/303/307/308 as redirects, not auth failures — don't throw on 303.
2. Preserve SameSite cookies across the redirect (a top-level-browsing-context net.fetch variant, or re-send the cookie explicitly), or make the welcome request not depend on a cross-site redirect.
3. At minimum, include the status and origin in the error instead of a generic Web authentication failed.

Workaround (reference only, not a recommendation)

Patching lib/main.js — tolerate 303 + plain fetch with an explicit cookie header (2 hunks) — makes it stable, but requires ad-hoc re-signing, which breaks notarization and auto-update. So it should be fixed upstream. Full diff available on request.

[HuHong-Tao]

Definitive root cause (confirmed on 0.2.2-rc.1, macOS arm64)

This is not a plugin problem and not a 303-handling problem. The Host returns 431 Request Header Fields Too Large because the Electron default session has accumulated one dsh-auth-* cookie per past launch.

• Each Desktop launch picks a random Host port. authenticateWebHost gets a 30-day dsh-auth-* cookie, and connectDesktopWelcome(..., net.fetch(..., { credentials: 'include' })) lets the default Electron session store it.
• Cookies ignore ports. Every launch adds another dsh-auth-* cookie for 127.0.0.1, so every request to the Host carries all of them.
• After roughly 70 launches the Cookie header exceeds Node's 16 KiB maxHeaderSize; the Host answers 431, authenticated.ok is false at app.asar/lib/main.js:16856, and boot aborts before any plugin service is wired.

Measured on the affected machine:

• ~/Library/Application Support/@deepseek-ai/dsh-desktop/Cookies contained 71 rows with name LIKE 'dsh-auth-%', all with host_key = '127.0.0.1'.
• Reproduced against the 0.2.2-rc.1 bundled Host: a 226-byte Cookie header gets 200; a 17,588-byte Cookie header gets 431.
• This matches the "worked for a while, then every launch fails" pattern, and explains why "Disable third-party plugins" cannot help — the handshake dies before plugins are mounted.

Correction to the earlier comment: the 303 is handled correctly — authenticateWebHost uses redirect: 'manual' and extracts the cookie. The failing request is the second fetch inside connectDesktopWelcome, which follows the redirect through the session jar and ends at 401/431, not 303. Treating 303 as "ok" would not fix it.

Upstream fix (already on master, not in 0.2.2-rc.1)

• 5868dbc35 — "fix(desktop): stop storing Host auth cookies in the Electron session": connectDesktopWelcome(hostUrl, cookie) sends the Cookie header explicitly with no cookie jar; the account WebSocket reuses that same cookie.
• 93bef27ec — "fix(desktop): remove legacy Host auth cookies from the default session": deletes every dsh-auth-* cookie for the Host hostname at startup.

Workaround for affected users

Quit the app and delete the accumulated cookies once; startup returns until ~70 more launches:

sqlite3 "$HOME/Library/Application Support/@deepseek-ai/dsh-desktop/Cookies" \
  "delete from cookies where host_key='127.0.0.1' and name like 'dsh-auth-%';"

(Backporting the two commits also works, but needs an ad-hoc re-sign and is overwritten by auto-update.)

Please ship these two commits in the next RC — the cookie leak alone makes every long-lived desktop install fail after roughly 70 launches.

[zhengshupei-dshhub]

Confirming on my machine (the original reporter): the 431 cookie-accumulation analysis is correct for the persistent variant, and the two master commits exist, but my crash was a different, transient trigger. Some data from this side:

1. The fix commits are real, and my 0.2.2-rc.1 build does not include them.
5868dbc35 and 93bef27ec both exist on master. The notarized 0.2.2-rc.1 desktop build still bundles the pre-fix main.js — at line 20386 it still calls connectDesktopWelcome(ready.url, (input, init) => net.fetch(input, init), …), i.e. no explicit Cookie header and no startup cleanup. So the leak is live in the shipped RC.

2. This 431 root cause does not explain my original crash.
At the time of my crash loop (5 failures, 09:17–09:32 +08:00) my Cookies DB held only 2 dsh-auth-* cookies (~350 bytes total header), two orders of magnitude below the 16 KiB limit. And the failure mode differs: 431 is monotonic ("works until it never works, fixed only by clearing cookies"), whereas mine self-healed after a full process restart. The generic Web authentication failed message hid the real status code, which is exactly why this was hard to pin down — worth fixing regardless of which root cause.

3. But the leak is real and already ticking on my machine too.
Each successful launch adds one 30-day dsh-auth-* cookie under 127.0.0.1. At 2–3 launches/day that reaches the ~70 threshold in about a month. I've added a read-only cookie count to my daily quota guard (alerts at ≥40) so I get a heads-up before the crash line, and I'll clear them manually until a fixed RC ships.

Thanks for the thorough isolation — the request-header-size repro (226-byte → 200, 17,588-byte → 431) is the key evidence. Agreed these two commits should land in the next RC.

[hisence999]

Independent Windows verification: same root cause, reproduced end-to-end

Confirming the 431 / dsh-auth-* accumulation analysis from @HuHong-Tao on Windows x64, with a byte-exact reproduction and the exact threshold between success and failure.

Environment

• DSH desktop 0.2.2-rc.1, Electron 44.7.0, Node 24.21.0, win32 x64
• Crash log: %APPDATA%\@deepseek-ai\dsh-desktop\logs\crash-2026-11-07T10-10-38-698Z-host.log
• Cookies DB: %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies

1. Same failure signature

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

Note that the crash log itself contains no 431 — only the generic message and the stack. The status code is only observable via netlog, which is exactly the diagnosability gap the earlier comment asked to fix. Confirming: !authenticated.ok does not distinguish 401 from 431.

2. Cookie DB measurements (71 rows, byte-exact)

total cookies: 71
dsh-auth-*:    71
all host_key:  127.0.0.1
name length:   52  (uniform)
value length:  173 (uniform)
path:          /   (all)
distinct name: 71  (all unique)
earliest creation_utc: 2026-10-17T02:47:07Z
latest   creation_utc: 2026-11-07T09:59:30Z

Concatenated as a single Cookie: header this is 16,194 bytes — already past http.maxHeaderSize, which is 16384 on the bundled Node. Adding UA/Accept/etc. lands around 16,561 bytes total request header size.

3. Naming is authority-bound, which is why they never get cleaned up

Verified in the shipped app.asar:

const COOKIE_PREFIX = "dsh-auth-";
function cookieName(authority) {
    return COOKIE_PREFIX + encodeBase64Url(createHash("sha256").update(authority).digest());
}

"dsh-auth-" (9) + base64url(sha256) (43) = 52 characters, matching every measured row. The Host is launched with a hard-coded --port 0:

args: ["--no-open", "--host", "127.0.0.1", "--port", "0"]

so every launch yields a fresh random port → fresh authority → fresh cookie name → a new row appended, none of the old ones removed. The documented behaviour agrees: cookies "bind the normalized hostname plus port in both their deterministic name and signed payload."

4. Threshold reproduced against a live 0.2.2-rc.1 Host

Rather than only testing the two extremes, I bisected the cookie count against a running Host (http://127.0.0.1:<port>/?token=...), sourcing real header composition:

cookies	Cookie: header bytes	response
1	226	401
60	13,678	401
65	14,818	401
68	15,502	401
71	16,186	431 Request Header Fields Too Large
75	17,098	431

The transition sits between 68 and 71, i.e. exactly at the 16,384-byte boundary — the leak is monotonic and the last few launches are what cross the line, which is why installs "work for a while, then never start again."

5. Local build genuinely lacks both fixes

0.2.2-rc.1 at lib/main.js byte offset 212248626 still contains the pre-fix call site:

hostCookie = await authenticateWebHost(ready.url);   // cookie already obtained here
hostUrl = ready.url;
...
welcomeBackend = await connectDesktopWelcome(ready.url, (input, init) => net.fetch(input, init), async () => ...);

authenticateWebHost already returns the correct authority-bound Cookie header — the value is captured into hostCookie and then simply not passed to connectDesktopWelcome, which instead routes through net.fetch and therefore through the default Electron session's cookie jar. So 5868dbc35 + 93bef27ec are absent from this build, as @zhengshupei-dshhub also observed.

One correction to my own earlier assumption, in case others are reading: the "Disable third-party plugins" button cannot help here, because the handshake aborts at main.js:20386 before any plugin service is wired. That matches the original report's observation that crashes continued with a minimal patch.

Request: please ship 5868dbc35 and 93bef27ec in the next RC. Combined with the third suggestion from the earlier comment — include the HTTP status and origin in the Web authentication failed error — this class of failure becomes diagnosable from the crash log alone instead of requiring netlog forensics.

For anyone hitting this on the way to a fixed build, the one-time cleanup quoted by @HuHong-Tao works on Windows as well, with the DB at %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies. The app must be fully quit first — the file is exclusively locked while running. Cleaning only host_key='127.0.0.1' AND name LIKE 'dsh-auth-%' and keeping the newest row is safe, since only the current authority's cookie is ever valid.

[gcheng001]

Confirmed on 0.2.2-rc.1 (notarized, macOS arm64, 2026-11-08): identical stack (connectDesktopWelcome at app.asar/lib/main.js:16856), same crash loop, and the crash dialog's "Disable third-party plugins" path does not help.

Two additions beyond #12377 / #11758:

1. Byte-exact accounting of the cookie jar. Summing the Cookies SQLite DB: 71 rows matching dsh-auth-% on host 127.0.0.1 total 16,259 bytes of name+value pairs; with separators and Cookie: framing the header reaches ~16.2 KB, and once User-Agent/Host/Sec-Fetch-* are added the request crosses Node's default 16,384-byte header cap. Timeline: the last good launch (07:49 local) carried 69 stale cookies (~15.7 KB) and survived; the next launch (07:51) got a 303 on the initial request, but the redirect-follow carried 71 (~16.2 KB) and got 431; every later launch failed on the initial request with all 71 stale cookies attached.

2. The jar stops storing after the threshold. Polling the Cookies DB at 0.5 s intervals during failing launches shows zero new dsh-auth-* rows — the last stored row predates the failure window. After clearing the rows, the next boot stores a fresh cookie and starts cleanly, which ties the whole loop to the header overflow (no second bug behind it).

Workaround until a fix ships — quit the app, then:

sqlite3 ~/Library/Application\ Support/@deepseek-ai/dsh-desktop/Cookies \
  "DELETE FROM cookies WHERE name LIKE 'dsh-auth-%' AND host_key='127.0.0.1';"

At ~262 bytes per launch it recurs after roughly 70 more launches. Pruning stale dsh-auth-* rows at host boot, or raising the host's header cap, would fix it permanently.

[aturzone]

The 431/cookie chain is now confirmed across this thread, #12360, and #12606. Two facts from the source side that close the loop:

1. The fixes exist in master and are older than the release. 5868dbc35 (2026-10-31, "stop storing Host auth cookies in the Electron session") and 93bef27ec (2026-10-31, "remove legacy Host auth cookies from the default session") are in fcc0ad4621; connectDesktopWelcome on master authenticates without letting the default Session keep dsh-auth-* cookies. The notarized 0.2.2-rc.1 desktop build predates that code, so the shipped app still accumulates them — matching @zhengshupei-dshhub's byte-level finding. That is a build-pipeline gap, not a missing design.

2. The prune still had one ordering hole. On master, removeLegacyHostCookies() already ran, but as void ... .catch(...), so the welcome connection and the page could issue requests while stale cookies were still present. We prepared a hardening branch for that:

• fix/desktop-cookie-cleanup-order @ 495f17a0e4
• boot now awaits the prune before connecting the welcome backend / opening the page (a failed prune still logs and proceeds);
• ordering regression: with the old void call the welcome backend is connected before the prune resolves and the test fails; with the fix it passes;
• apps/desktop/tests/main-startup.spec.ts + web-document.spec.ts: 175 passed; typecheck 5/5; full lint 0.

Workaround for affected users today (until a desktop build includes the two commits): close DSH fully (tray → exit), then remove the accumulated cookies from %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies (or start with a fresh userData dir); do not rely on "Disable third-party plugins" for this, since it renames the whole profile patch and does not touch the cookie jar. Also note #12532/#11893 was a separate seam bug we fixed; and #12360's reporter asked for a configurable port range + shorter cookie lifetime — those are product choices, not required for the fix.

If maintainers want, the two ordering/branch changes can be cherry-picked independently of the build-pipeline fix.