Desktop app stops starting after ~70 launches: accumulated dsh-auth cookies exceed Node's 16 KiB header limit (HTTP 431)

[echo-125]

Desktop app stops starting after ~70 launches: accumulated dsh-auth cookies exceed Node's 16 KiB header limit (HTTP 431)

Environment

• DeepSeek Harness 0.2.1-rc.3 (desktop shell @deepseek-ai/dsh-desktop, bundled @deepseek-ai/dsh 0.2.1-rc.3)
• Electron 44.7.0, Node 24.21.0
• Windows 11 build 10.0.28000 x64
• Reproduces with the stock bundled runtime; third-party plugins are not required

Symptoms

The window opens but permanently shows "DeepSeek Harness is unavailable". Nothing is logged to the profile log directory. Launching the executable from a console prints:

dsh web: http://127.0.0.1:54392/?token=...
Error: desktop welcome: Web authentication failed
    at connectDesktopWelcome (resources/app.asar/lib/main.js:8886:31)
    at async Object.start (resources/app.asar/lib/main.js:12195:22)
    ...
Error occurred in handler for 'dsh-desktop:boot': Error: desktop welcome: Web authentication failed

The embedded Host itself boots fine (dsh web: ... is printed, plugins activate), and a fresh --user-data-dir starts normally. Deleting the loopback dsh-auth-* cookies from %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies fixes startup immediately.

Root cause

1. dsh-desktop-host starts the Web host with --port 0 (lib/index.js), so the loopback port is random on every launch.

2. BrowserAuth#authenticatedUrl() appends a per-process launch token to http://127.0.0.1:<port>/?token=....

3. BrowserAuth#authorizeIndex() mints a persistent cookie (30 days) named

   dsh-auth-<base64url(sha256("<host>:<port>"))>
   

   i.e. the cookie name contains the random port, so each launch creates a new cookie instead of overwriting the previous one.

4. Electron's default session sends every 127.0.0.1 cookie on each request. The cookies are never cleaned up, so the Cookie request header grows by ~224 bytes per launch.

5. Node's HTTP server uses the default maxHeaderSize of 16 KiB. Once the accumulated cookies plus the standard Chromium request headers cross that limit, the Host answers 431 Request Header Fields Too Large before the route handler runs.

6. The desktop shell's authenticateWebHost() / connectDesktopWelcome() receive a non-OK response and fail the boot with desktop welcome: Web authentication failed.

In this report the profile had 71 cookies, one per launch since 2026-10-17.

Evidence

• Cookies DB: 71 rows, all host_key = 127.0.0.1, all named dsh-auth-<hash>, value length 173 bytes (~16.2 KiB of raw cookie header).

• Direct Host reproduction (spawn dsh-desktop-host, request the authenticated launch URL with N cookies and normal Chromium headers):

  cookies sent	status
  0	303 See Other
  70	431 Request Header Fields Too Large
  71	431 Request Header Fields Too Large

• After deleting only the loopback dsh-auth-* cookies, the same installation starts normally and re-mints a single cookie.

Reproduction

1. Use a fresh profile.
2. Launch and quit the desktop app repeatedly. Each successful boot leaves one additional persistent dsh-auth-* cookie.
3. After roughly 70 launches, the next launch fails with the symptoms above.

(Equivalent: seed the Electron session with ~70 dsh-auth-* cookies for 127.0.0.1 and launch.)

Suggested fixes

Any one of these resolves it; the first two also prevent recurrence:

1. Use a port-independent cookie name (e.g. a constant dsh-auth). Cookies are already scoped by host, not by port, so a constant name makes each launch overwrite the previous cookie.
2. Prune stale cookies at startup: delete dsh-auth-* cookies for the loopback host whose name does not match the current authority — they can never authenticate again.
3. Raise the Host's header limit as defense in depth, e.g. http.createServer({ maxHeaderSize: 64 * 1024 }).
4. Improve the failure message so a 431/401 at boot says which response was received instead of only "Web authentication failed".

Additional observation

All 71 cookies are stored unencrypted in the Cookies SQLite database (value column populated, encrypted_value empty). On Windows, Chromium normally encrypts cookie values with DPAPI/os_crypt; this may indicate an os_crypt fallback. It is not the cause of the startup failure, but it may be worth a separate look.

Local workaround

Delete the loopback dsh-auth-* rows (or the whole Network\Cookies file) while the app is closed. Only the local desktop web session is lost; no account credentials are affected.

[drscrewdriver]

pnpm install dsh-cookie-cleaner

① 先看现状（客户端开着也能跑，只会告诉你读不到）

& "$env:USERPROFILE.dsh\profiles\desktop\node_modules.bin\dsh-cookie-cleaner.cmd"

② 完全退出客户端：托盘图标 → 退出，并确认进程列表已无 DeepSeek Harness

Get-Process | Where-Object { $_.ProcessName -match 'DeepSeek|dsh' } # 应当没有输出

③ 清理（先看会删几条，再真删）

& "$env:USERPROFILE.dsh\profiles\desktop\node_modules.bin\dsh-cookie-cleaner.cmd" --clean --dry-run
& "$env:USERPROFILE.dsh\profiles\desktop\node_modules.bin\dsh-cookie-cleaner.cmd" --clean