Desktop: dsh-auth-* cookies accumulate on every launch and eventually overflow the request-header limit (0.2.1-rc.5)

[Xavier-73]

Summary

The Desktop shell starts its Host with --port 0, so the port is random on every launch.
The session cookie is named dsh-auth- + sha256(authority), and the authority includes
that port. Each launch therefore mints a new, persistent cookie while the old ones are
never removed, so they accumulate in the 127.0.0.1 jar and are all sent on every request.
The Cookie: header grows ~228 bytes per launch until it exceeds Node's default
maxHeaderSize (16384), after which requests fail with HPE_HEADER_OVERFLOW / HTTP 431 —
visible to users as "authentication crashes".

Environment

DeepSeek Harness Desktop 0.2.1-rc.5 (macOS), packages
dsh-desktop-host, dsh-client-connection, dsh-host-webserver at the same version.

Reproduction

Cookies live in ~/Library/Application Support/@deepseek-ai/dsh-desktop/Cookies (SQLite).

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

Launch the app, quit, relaunch, re-run the query: the count increases by one every
launch. After 13 launches over 5 days:

source_port | name
------------+------------------------------------------------------
      65442 | dsh-auth-Plol2NXF0i-DgPiS7rrCiC_4zyP6amfaAnYISbyeWlY
      56812 | dsh-auth-yt0y9TaGSWBr8JAFmN-bKMsRKhq7YtbDvXTK65bIaOg
      60054 | dsh-auth-QdvUOXx7yIPrZo_9MG5kRg1pGM-SPYgeRr9qwokjPQM
      58289 | dsh-auth-CGhAi2HdSkwE2GNrvyqhDwD4GWLAz6Ekc1VMiACQMpA
      58353 | dsh-auth-vJIRLjRe3p4TWlsOTJ94vH70InfaDNHeFSLZXWwTR9Q
      59270 | dsh-auth-2DdF5dqPFCWTkE7pQi7fgV8VHBTbP79DWsc4ISUQc84

All rows: host_key = 127.0.0.1, is_persistent = 1, 228 bytes each (52-char name +
173-byte value) → 2964 bytes of Cookie: header after 13 launches.

Root cause

1. Hard-coded --port 0 — dsh-desktop-host/lib/index.js:

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

2. Cookie name embeds the port — dsh-client-connection/lib/index.js:

function cookieName(authority) {
  return "dsh-auth-" + encodeBase64Url(createHash("sha256").update(authority).digest());
}
function requestAudience(headers, secure) {
  const url = new URL(`${secure ? "https:" : "http:"}//${host}`);
  return secure ? url.origin : url.host;   // <-- includes the port
}

Unlike-named cookies never overwrite each other, so every port change adds a row.
Verified: sha256("127.0.0.1:50299") reproduces the exact name in the jar.

3. Nothing ever cleans them up — there is no cookies.remove() in the shell, and
cleanStorage() only clears the per-account partition, not defaultSession:

await browserSession.clearStorageData(browserSession.isPersistent() ? { storages: [
  "cookies", "filesystem", "indexdb", "shadercache", "serviceworkers", "cachestorage"
] } : void 0);

4. Duplicates cannot be collapsed downstream — the shell forwards with
headers.set("cookie", cookie) and withholds set-cookie from the renderer, while the
Host-side mergePlatformCookies() only de-duplicates the injected pair.

Impact

~71 launches (≈4 weeks at 3/day) reach 16384 bytes and every request then fails.
Proxies or CDNs with a lower header cap fail sooner.

Suggested fixes

1. Stop passing --port 0 (or default to a stable/configurable port). A fixed
   authority gives a stable name, so relaunches overwrite instead of append.
2. Drop the authority from the cookie name — use a fixed name and validate the
   authority already present inside the signed payload.
3. Purge stale dsh-auth-* cookies on startup, or extend cleanStorage() to
   defaultSession.

Workaround (verified on 0.2.1-rc.5)

Pin the port via the profile patch layer — no app.asar changes, so code signing and
asar integrity validation stay intact. Append to ~/.dsh/profiles/desktop/cordis.patch.yml:

- id: webserver
  config:
    host: '127.0.0.1'
    port: 3080
    compression: gzip
    compressionLevel: 1
    compressionThresholdBytes: 1024

Result after one relaunch: rows 13 → 1, Cookie: header 2964 → 226 bytes, port
fixed at 3080. The single row's name matched the predicted
sha256("127.0.0.1:3080") → dsh-auth-VPhEEcLKeqRDBoBalzN2Nm7CnfxKhLE00pKIDWxt1sw,
confirming that a fixed authority yields in-place overwrite.