Desktop app fails to open with "Web authentication failed" after ~70 launches — accumulated dsh-auth cookies exceed the 16 KB header limit (431)

[chAngE-98]

Environment

• Windows 11 x64, DSH Desktop 0.2.1-rc.3 (Electron 44.7.0, Node 24.21.0), installed at D:\APPs\DeepSeekHarness
• Same behavior on 0.2.1-rc.2
• Reproduced across two instances of the app; nothing else changed (no new plugins, disk/permissions fine)

Symptom

Double-clicking the app produces no window, or a window that dies immediately. stderr repeatedly shows:

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

while stdout shows the Host already up:

dsh web: http://127.0.0.1:<random port>/?token=...

So the server side is healthy — the handshake fails. 10 consecutive launches produced 10 identical crash-*-host.log entries.

Root cause (Chromium netlog evidence)

1. Every launch, the Host issues a one-time login cookie dsh-auth-<random>; it is persistent with a 30-day expiry, and its value encodes authority: 127.0.0.1:<port of this launch>.
2. HTTP cookies are scoped by host, not by port. The desktop app picks a random port on every launch, and the cookie name is random too, so old cookies are never overwritten — they just pile up.
3. connectDesktopWelcome() performs GET /?token=... through Chromium's network stack. A netlog capture shows all historical dsh-auth-* cookies sent in the single Cookie header, each with COOKIE_INCLUSION_STATUS: INCLUDE, WARN_PORT_MISMATCH (port mismatch does not exempt them).
4. Node's HTTP server uses the default maxHeaderSize = 16 KB. On this machine there were 71 cookies × 227 bytes = 16,117 bytes of cookie header (name 52 B + = + value 173 B + ; ), plus Cookie: and the regular headers ≈ 16.5 KB → the Host answers 431 Request Header Fields Too Large (2 occurrences in netlog).
5. response.ok === false → "Web authentication failed". Triage is misled because authenticateWebHost() uses Node's fetch (no cookie jar, only the ?token=), which always succeeds.

Cookie DB (%APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies): 71 rows, all host_key='127.0.0.1', all named dsh-auth-*, value bytes total 12,283.

Workaround (recovers the app)

Quit DSH completely, then:

// node:sqlite (Node >= 22.5)
const db = new DatabaseSync(`${process.env.APPDATA}\\@deepseek-ai\\dsh-desktop\\Network\\Cookies`);
db.prepare("DELETE FROM cookies WHERE host_key='127.0.0.1' AND name LIKE 'dsh-auth-%'").run();
db.exec('PRAGMA wal_checkpoint(TRUNCATE)');

Then start DSH again. (Back up the file first; it is SQLite.)

⚠️ It recurs in ~1 month: steady state ≈ 30 days (expiry) × launches per day. At 2–3 launches/day that is ~60–90 cookies, i.e. always at the limit. Expiry does not help — the expiry rate equals the accumulation rate.

Suggested fixes (any one is enough)

1. Use a fixed cookie name per authority (e.g. dsh-auth + hash of the port) so a new launch overwrites the old one instead of adding a new one.
2. Use a session cookie instead of a 30-day persistent one.
3. Partition cookie storage by origin including port (supports this per spec; Chromium would then isolate ports).
4. Prune stale dsh-auth-* cookies on startup, before the handshake.
5. (Last resort) Raise maxHeaderSize on the Host HTTP server — hides the leak instead of fixing it.

Happy to provide the full netlog capture and the crash logs.

[Aresitoo]

same problem can't login can't use the harness