Desktop: dsh-auth-* cookies accumulate on every launch and eventually break startup ("Web authentication failed")

[pmc19980323-web]

Summary

On Windows desktop (@deepseek-ai/dsh-desktop 0.2.1-rc.3, electron 44.7.0, node 24.21.0), every launch mints a new dsh-auth-* cookie for 127.0.0.1 in the Electron session jar. Nothing ever removes the old ones. After roughly 70 launches the Cookie header sent by the welcome handshake (connectDesktopWelcome) exceeds Node's default 16 KiB header limit, the request is rejected, and the app no longer starts:

Error: desktop welcome: Web authentication failed
    at connectDesktopWelcome (app.asar/lib/main.js)

Because startup fails, the built-in retry loop crashes ~8 times, and the app then enters its recovery mode ("Disable third-party plugins, back up profile patch, and restart"), which additionally empties dsh.profile.bundles in the profile's package.json — so all third-party plugins silently disappear as a side effect.

Environment

• Windows 11 x64
• @deepseek-ai/dsh-desktop 0.2.1-rc.3 (latest nightly as of 2026-10-23)
• Installed 2026-10-25; the app had been launched 70+ times since
• Cookie jar: %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies

Steps to reproduce

1. Start and quit the desktop app repeatedly (~70 times). Each launch adds one cookie named dsh-auth-<43 random chars> for host 127.0.0.1.
2. Watch the jar grow: select count(*) from cookies where name like 'dsh-auth-%'.
3. Around the 72nd launch the app stops starting: the error dialog appears, and %APPDATA%\@deepseek-ai\dsh-desktop\logs\crash-*-host.log contains the error above.

Evidence from our machine

• Before the failure the jar contained 71 dsh-auth-* cookies (53,248-byte SQLite file).
• After a failed start the count stays at 71 — the new cookie cannot be stored because the request carrying it was rejected — so the app is stuck: every retry fails the same way.
• Deleting the cookie jar (the app recreates it) restores startup immediately, which confirms the cause is header size, not credential expiry.
• Cookie names alone are 52 chars (dsh-auth- + 43), and each name=value; pair is well over 150 bytes once the encrypted value is counted, so ~72 entries is exactly where a 16 KiB header blows up.

Expected

The desktop shell should prune stale auth cookies, so long-term users do not hit a hard wall.

Suggested fix

In the main process, before the welcome handshake (or right after a successful one):

• remove all session.defaultSession.cookies entries whose name starts with dsh-auth- except the one just issued, or
• remove dsh-auth-* entries older than e.g. 7 days, or
• store the auth token in a single cookie that is overwritten instead of appended.

A defensive check before net.fetch(url, { credentials: 'include' }) that measures the serialized cookie size and rotates the jar above a threshold (e.g. 12 KiB) would also prevent the hard failure.

Workaround we use

A pre-launch step reads Network\Cookies with sqlite, sums len(name)+len(value)+2 for every dsh-auth-* entry, and moves the jar aside (the app recreates it) when the estimated header exceeds 12 KiB. Rotating the jar is safe because each launch mints a fresh cookie anyway.

Additional observation

When startup crashes consecutively, recovery mode strips the profile patch and empties dsh.profile.bundles, silently disabling every third-party plugin (all plugin tools disappear from the session). Recovering from that is non-obvious for users; a warning or a "restore plugins" action would help.