Issue: Desktop startup fails with desktop welcome: Web authentication failed after stale dsh-auth-* cookies exceed the 16 KB header limit (HTTP 431)

[CalciumSparks]

Desktop startup fails with desktop welcome: Web authentication failed after stale dsh-auth-* cookies exceed the 16 KB header limit (HTTP 431)

Environment

• App: @deepseek-ai/dsh-desktop 0.2.2-rc.1
• Electron: 44.7.0
• Node: 24.21.0
• OS: Windows 11 26H2, build 26300.9711, x64
• Locale: zh-CN
• Update channel: nightly

Summary

The desktop app fails during startup and shows the fatal recovery dialog:

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

The failure is not caused by a corrupted installation, the .dsh profile, or third-party plugins.

It is caused by unbounded accumulation of local authentication cookies in Electron's default session:

1. The Desktop Host listens on a random loopback port on every launch (--port 0).
2. The browser-session cookie name is derived from the request authority including the ephemeral port:
   dsh-auth-<base64url(sha256("127.0.0.1:<port>"))>.
3. The cookie is persistent with a 30-day lifetime (cookieMaxAgeDays default: 30).
4. Therefore every launch creates a new cookie instead of replacing the previous one.
5. connectDesktopWelcome() authenticates with Electron net.fetch(..., { credentials: "include" }), which sends all cookies stored for 127.0.0.1.
6. After roughly 70 launches within 30 days, the resulting Cookie request header exceeds Node's default 16 KB maxHeaderSize. The Host's HTTP server rejects the request with HTTP 431 Request Header Fields Too Large.
7. connectDesktopWelcome() only checks authenticated.ok and reports every non-2xx response as desktop welcome: Web authentication failed, hiding the real 431.

Deleting the stale dsh-auth-* cookies immediately restores startup.

Actual behavior

• The main window never opens.
• A crash report is written to:
  %APPDATA%\@deepseek-ai\dsh-desktop\logs\crash-<timestamp>-host.log
• The report contains:

time: 2026-11-08T02:34:51.987Z
source: host
phase: startup
app: @deepseek-ai/dsh-desktop 0.2.2-rc.1
platform: win32 x64
electron: 44.7.0
node: 24.21.0
locale: zh-CN

--- error ---
Error: desktop welcome: Web authentication failed
    at connectDesktopWelcome (file:///.../resources/app.asar/lib/main.js:16856:31)
    at async Object.start (file:///.../resources/app.asar/lib/main.js:20386:22)
    at async file:///.../resources/app.asar/lib/main.js:13648:5
    at async file:///.../resources/app.asar/lib/main.js:20520:4

--- renderer console (error level, oldest first) ---
(no error-level renderer console output was captured)

--- recent plugin operations (context, not proof of cause) ---
{"journal":null,"bytesRead":0,"filesRead":0,"truncated":false,"invalidRecords":0,"unavailableFiles":0,"cancelled":false,"outputRecordsOmitted":0,"records":[]}

• No renderer errors were captured.
• The plugin operation journal was unavailable/empty, so plugins are not implicated.
• Using the “disable third-party plugins, back up profile patch and restart” recovery action did not help; the same error occurred again.

Expected behavior

The app should start normally even after many launches, and stale local authentication cookies should not cause an unbounded Cookie header.

A non-2xx response should also produce a diagnostic containing the real HTTP status instead of a generic authentication error.

Reproduction

Natural reproduction

1. Use the desktop app normally over several days.
2. Each launch starts the Host on a different random port and creates another dsh-auth-<port-hash> cookie with a 30-day expiry.
3. After approximately 70 launches within 30 days, restart the app.
4. Startup fails with desktop welcome: Web authentication failed.

Deterministic cookie-header reproduction

With the app closed, pre-populate the default Electron session with many cookies for 127.0.0.1 (cookies are host-scoped, not port-scoped):

const { session } = require('electron');

for (let i = 0; i < 80; i++) {
  await session.defaultSession.cookies.set({
    url: 'http://127.0.0.1:1/',
    name: `dsh-auth-${i}`,
    value: 'x'.repeat(180),
    path: '/',
    httpOnly: true,
    sameSite: 'strict',
    secure: false,
    expirationDate: Date.now() / 1000 + 30 * 86400,
  });
}

Then start the app. The shell's authenticated net.fetch() request receives HTTP 431 and fails with the same message.

Evidence

1. Cookie database contained 71 stale dsh-auth-* cookies

Query against %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies:

SELECT count(*)
FROM cookies
WHERE name LIKE 'dsh-auth-%';
-- 71

Summing length(name) + length(encrypted_value) for those rows gives approximately 16.2 KB, which is already at/above Node's default 16 KB request-header limit once the rest of the request headers are included.

All rows had:

• host_key = '127.0.0.1'
• a 30-day expiry
• created across normal app launches

2. Node fetch() succeeds while Electron net.fetch() fails

With the Host running:

Node fetch(url, { redirect: 'manual' })
  -> 303, Location: ./, Set-Cookie: dsh-auth-...   (success)

Electron net.fetch(url, { credentials: 'include' })
  -> 431, connection: close, empty body            (failure)

The Node path (authenticateWebHost) does not use a cookie jar, so it never sends the accumulated cookies. The Electron path does use the default session and sends all of them.

After deleting the 71 dsh-auth-* cookies and restarting, the app started normally and no new crash report was produced.

Root cause in code

Relevant code paths (0.2.2-rc.1):

• @deepseek-ai/dsh-client-connection — browser authentication:
  • cookieName(authority) returns dsh-auth- + base64url(sha256(authority)).
  • For HTTP, requestAudience() returns url.host, which includes the ephemeral port.
  • sessionCookie() writes Max-Age=2592000 (30 days) by default.
• @deepseek-ai/dsh-desktop-host — starts the Web server with --port 0, so the authority changes on every launch.
• @deepseek-ai/dsh-desktop — lib/main.js:
  • authenticateWebHost() uses Node fetch(..., { redirect: "manual" }) and returns the cookie without storing it.
  • connectDesktopWelcome() then uses net.fetch(ready.url, { credentials: "include" }).
  • if (!authenticated.ok) throw new Error("desktop welcome: Web authentication failed") loses the actual status.

Because Chromium cookies are not port-scoped, all previous dsh-auth-* cookies for 127.0.0.1 are sent to the newly started Host, even though only one of them can match the new authority.

Suggested fix

1. Use a stable cookie name that does not include the ephemeral port.
   Cookie names are not port-scoped. A single name such as dsh-auth is sufficient because the launch-token exchange re-mints the cookie on every launch and overwrites the previous value. Keep the authority binding inside the signed cookie payload.

2. Or clean up stale cookies before minting a new one.
   Before connectDesktopWelcome() / at shell startup, delete all dsh-auth-* cookies for 127.0.0.1 from the Electron default session, then exchange the launch token for a fresh cookie.

3. Or stop using the default cookie jar for this request.
   Use a dedicated session.fromPartition() for the welcome backend, or pass the cookie obtained by authenticateWebHost() explicitly instead of using credentials: "include" with the default session.

4. Preserve the real HTTP status in diagnostics.
   Include response.status (and a small response body when present) in the error. A 431 should be distinguishable from a genuine 401/403 authentication failure.

5. Add a regression test.
   Simulate many launches / pre-populate many dsh-auth-* cookies and assert that startup still succeeds and that the number of cookies (or request-header size) stays bounded.

Lowering cookieMaxAgeDays only delays the problem and can break long-running sessions; it is not a complete fix.

Workaround for users

1. Close the app.
2. Delete only the local desktop authentication cookies:
   • Either delete %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies
   • Or delete rows with name LIKE 'dsh-auth-%' from that SQLite database.
3. Restart the app.

This does not sign the user out of the DeepSeek platform account; it only clears the local Host browser-session cookies.

A small launch wrapper can also purge dsh-auth-* cookies before every app start to prevent recurrence.

Impact

• Affected users: desktop/nightly users on 0.2.2-rc.1 after enough launches within the 30-day cookie lifetime.
• Severity: high for affected users — the app becomes unusable until the cookie database is cleaned.
• Data loss: none observed; .dsh user data (credentials, sessions, storages, profiles, skills, plugins) was intact.
• Recoverability: high; deleting the local authentication cookies restores startup.

[aturzone]

Same root cause as #12502/#12360: the desktop build accumulates dsh-auth-* cookies because the random port changes each launch while Chromium scopes cookies by host. The fix commits 5868dbc35 and 93bef27ec (2026-10-31) are in master (fcc0ad4621) but predate the 0.2.2-rc.1 desktop bundle; we also hardened the remaining ordering gap in fix/desktop-cookie-cleanup-order @ 495f17a0e4 (await the prune before the boot continues; ordering regression included).

Practical recovery until a fixed desktop build ships: fully quit DSH (tray → exit), remove the stale cookies from %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies (or launch with a fresh userData directory), then restart. "Disable third-party plugins" will not clear them. Details and source lines are in the #12502 reply.