[Bug][Desktop 0.2.1-rc.3] Auth cookies accumulate across restarts, causing HTTP 431 and startup failure

[lookyouforever]

Summary

DeepSeek Harness Desktop 0.2.1-rc.3 can fail to launch after repeated restarts with the following error:

Error: desktop welcome: Web authentication failed

I investigated this issue on macOS arm64 and identified a reproducible cause: stale authentication cookies accumulate across launches until the HTTP Cookie header exceeds Node.js's default 16 KB request-header limit.

The server then returns HTTP 431, which the Desktop application incorrectly reports as an authentication failure.

I verified that clearing the stale cookies restores the application without reinstalling it.

Environment

Component	Version
DeepSeek Harness Desktop	0.2.1-rc.3
Electron	44.7.0
Node.js	24.21.0
Operating system	macOS arm64
Locale	zh-CN

The application passed code-signature and integrity verification.

Root Cause Analysis

1. The local host listens on 127.0.0.1 using a new random port on each launch.
2. The authorization flow issues a cookie named dsh-auth-<base64url(sha256(authority))>, where authority includes the randomly assigned port.
3. HTTP cookies are scoped by hostname and path, not by port. Cookies from earlier launches are therefore sent to the new host port.
4. Those older cookies cannot authenticate the current host because their signed payload refers to a different authority.
5. The cookies remain in Electron's persistent session for up to 30 days, so repeated launches can accumulate many obsolete cookies.

In the affected session, I measured:

Measurement	Observed value
dsh-auth-* cookies	71
Cookie name length	52 bytes each
Cookie value length	173 bytes each
Combined name=value; entries	16,117 bytes
Node.js default HTTP header limit	16,384 bytes

Once ordinary HTTP headers are included, the request exceeds the limit and the server returns:

HTTP/1.1 431 Request Header Fields Too Large

The Desktop welcome handler checks only whether the response is successful and reports HTTP 431 as a generic authentication failure. The subsequent recovery guidance incorrectly recommends reinstalling the application, although reinstalling does not necessarily remove persistent Electron cookies.

Direct Verification

I reproduced the welcome request using Electron's net.fetch:

const response = await net.fetch(readyUrl, {
  credentials: "include"
});

Observed results:

• Before cookie cleanup: HTTP 431
• After cookie cleanup: HTTP 200
• Remaining authentication cookies: 1

The application installation and user profile remained unchanged. This supports cookie accumulation, rather than corrupted application files, as the immediate cause of this failure.

Steps to Reproduce

1. Install and launch DSH Desktop 0.2.1-rc.3.
2. Repeatedly start and quit the application, approximately 70 times within the 30-day cookie lifetime.
3. Launch Desktop again.
4. Observe the Web authentication failed error.
5. Inspect the local welcome request and confirm HTTP 431.
6. Fully close Desktop and remove stale dsh-auth-* cookies from its Electron session.
7. Restart Desktop and confirm successful authentication.

For deterministic regression testing, seed a fresh Electron session with approximately 70 dsh-auth-* cookies for http://127.0.0.1/, each with a value close to 173 bytes, before attempting the welcome handshake.

Suggested Fixes

Immediate mitigation

Remove stale local authentication cookies before initiating the Desktop welcome handshake:

async function clearStaleHostAuthCookies(session) {
  const stale = (
    await session.cookies.get({ url: "http://127.0.0.1/" })
  ).filter(({ name }) => name.startsWith("dsh-auth-"));

  for (const { name } of stale) {
    await session.cookies.remove("http://127.0.0.1/", name);
  }
}

Long-term improvements

1. Use a stable, bounded authentication cookie name instead of generating a new name for every ephemeral port. Review concurrent-host behavior when implementing this change.
2. Consider isolating authentication cookies in a dedicated Electron session or local hostname.
3. Distinguish HTTP 431 from genuine authentication failures and include the HTTP status in diagnostics.
4. Avoid recommending application reinstallation for cookie-header overflow.
5. Add regression tests covering repeated Desktop launches, successful authentication and bounded cookie counts.

Relevant Code Locations

Based on the packaged Desktop 0.2.1-rc.3 runtime:

• app.asar/lib/main.js: authenticateWebHost() around line 8229.
• app.asar/lib/main.js: connectDesktopWelcome() around lines 8882–8886.
• @deepseek-ai/dsh-client-connection/lib/index.js: authenticatedUrl() around line 440, authorizeIndex() around line 458, and default cookie age around line 1017.
• @deepseek-ai/dsh-host-webserver/lib/index.js: HTTP server creation around line 412.

Impact

This issue can make the Desktop application completely unusable after frequent restarts. The current error message also incorrectly suggests reinstalling the application.

I recommend treating this as a high-priority Desktop reliability issue.

I have already sent a detailed report to harness-service@deepseek.com on October 29, 2026.

Could the maintainers confirm this issue and consider adding a fix to an upcoming release?

I can provide sanitized logs and further reproduction details privately if needed. I have not included raw authentication cookies, launch tokens or the cookie database in this public discussion.

Thank you.

[lookyouforever]

I found an earlier discussion reporting the same root cause and measurements:

#11374

This appears to be the same HTTP 431 authentication-cookie accumulation issue.

I'm linking the two discussions to help maintainers consolidate investigation and tracking.

[DSE0131]

这个问题是真实存在的，我由于某些需求近期大量重启了dsh,出现了这个问题。对cookies进行清理后恢复了正常运行，且日志里观察到清理的cookies数量正是71，可见这并非偶发性的问题，71的上限确实限制着dsh的启动

[PerryLink]

Your root cause is the right one, and it is still unfixed in the newest tree.

I checked packages/client/connection/src/browser-auth.ts at f3803c96 (0.2.2-alpha.2): cookieName (:116-118) still hashes the whole authority, requestAudience (:84) still returns url.host / url.origin with the port, and sessionCookie (:131-140) still writes Max-Age without any deletion of older names. The file is byte-identical to the 0.2.1-rc.3 tag, so macOS and Windows behave the same here — this is not platform-specific.

Two additions for the report:

1. The desktop launches the host with --port 0 (apps/desktop-host/src/index.ts:36), which is why the authority changes per launch rather than only per update.
2. The 431 is produced before the welcome handler runs, so the "authentication failed" wording is doubly misleading: the request never reached authentication. The fix has to happen at the jar boundary (drop sibling dsh-auth-* cookies or key the name by host only), not in the auth error path.

Your linked #11374 is the same bug; between the two threads the useful signal is that this reproduces on macOS as well as Windows, so it is not an ACL or a Windows-specific cookie-store quirk.

Source read at f3803c96.

[ep7z6y7]

我也遇到了这个问题，以下是Claude代码的解决方法：问题已修复，应用程序现在可以正常启动了。##根因不是网络、账号或登录过期，而是本地Cookie请求头超出了主机进程16 KB的上限：-每次启动时，本地主机将随机分配端口，并签发一个dsh-auth-<hash(127.0.0.1:端口)> Cookie。由于端口每次都不同，旧Cookie永远不会被复用，而保质期是30天。-你的Cookie库里已经积累了71个dsh-auth-，合计16,117字节，加上其他请求头后超过Node HTTP 默认的16,384字节限制。- 本地主机直接返回431请求标题字段太大，电子的net.fetch拿不到响应成功，因此报桌面欢迎：网络身份验证失败。-这也每次为什么重试都失败，并且失败本身还会再写入一个Cookie让，问题持续加重。##验证过程-用Chromium网络日志复现：请求主机的真实响应是HTTP/1.1 431请求标题字段太大。-手动启动主机，用卷曲测试：单个Cookie返回303→200，说明服务端认证逻辑完全正常；带16.5 KB Cookie时立即返回431。-你给的崩溃日志本身只是表象，停在connectDesktopWelcome的！认证。好的，判断上。## 已做的修复1.已备份Cookie库到/tmp/dsh-extract/Cookies.before-fix。2.关闭应用程序后，从Cookie库删除了全部127.0.0.1的dsh-auth- Cookie。3.重新启动验证：主机正常运行、模型列表正常加载、没有新的崩溃日志、应用程序已在你屏幕上打开。配置文件和插件清单没有被改动过（cordis.patch.yml是应用程序运行时自己写入的）。##注意事项这个问题约1-2周后复发（阈值约70个饼干，你大约10天积累了71个）。长期方案有两个：-向DeepSeek反馈：签发的Cookie名称包含随机端口且不清理，建议主机提高maxHeaderSize或清理过期Cookie；-我可以帮你做一个登录项/定时脚本，在应用未运行时定期清理这些Cookie。需要的话告诉我，我来配置自动清理。
以及DeepSeek网页端的对话和回复：https://chat.deepseek.com/share/teiqexopvzxwpsgvgc

[DSE0131]

Thanks — both additions check out, and the 431-before-welcome point is the one that cost us the most time: the error names authentication, so we burned a round on reinstall before finding the jar. We're on a shipped app.asar here (Windows), so we can't patch the source. We put a pre-launch guard in front of the desktop app instead: when `dsh-auth-*` crosses a threshold it backs up the cookie store, prunes to the newest, snapshots/restores the profile, then starts the app. That's your first option implemented outside the app — it buys headroom but still mints one cookie per launch. Keying the name by host only is the real cure; if it lands, please also purge legacy `dsh-auth-*` whose suffix doesn't match the new key on write, or upgraded installs keep them for 30 days and can still hit 431. One more thing from this machine: the 431 doesn't stop at the welcome page — the failed launch goes through fatal recovery, which renames `cordis.patch.yml` to `.bak-<ts&gt;` and cuts `dsh.profile.bundles` from 35 to 2. Fixing the jar removes this trigger, but any startup failure walks the same path; looks like its own issue. If there's ever a patched build to try, I'm on Windows and glad to re-run the launch loop and report back.

[DSE0131]

谢谢你把 Chromium netlog 那组和 curl 对照（单 cookie 303→200、16.5 KB 直接 431）写出来，把「认证坏了」和「请求头爆了」分干净了，这个验证过程很有用。 我们这边也撞的是同一个问题，已经恢复了：把 127.0.0.1 下的 dsh-auth-* 全清了一遍，重启就正常。另外加了一个启动前的清理（每次启动先把旧 cookie 清到只剩一条，带备份），实测 2 条 → 1 条、新随机端口正常起。数字也对得上：我们数到的也是 71 条、约 16,117 B。 有一条友情提醒，可能你那边也会踩到：失败不一定停在欢迎页。这边有一次启动失败走了 fatal recovery——`cordis.patch.yml` 被改名成 `.bak-<时间戳&gt;`，`dsh.profile.bundles` 从 35 项砍到 2 项（包和 node_modules 都还在，但配置没了）。所以「删完 cookie 就好了、配置没动」可能是这次走运，不是必然；我担心连续失败几次，配置会跟着丢。建议顺手存一份 profile 快照。 关于长期方案，我说说我的顾虑，不一定对：调大 maxHeaderSize，我担心只是把「约 70 次」这个周期往后推，头还是会涨，还可能盖住下一个同类问题。我倾向根治在写 cookie 那一侧——名字按 host 而不是 authority（端口不进 hash），写入时顺手清掉同族旧 `dsh-auth-*`。（这个思路你可以交给Claudecode评估一下在你那台设备上的可行性 ）这跟 issue 里另一位说的 jar boundary 是同一处。 关于定时清理脚本，这边有两个已经踩过的坑希望对你有帮助：旧实例还没退完时，cookie 库被独占锁，点起来会静默没反应（要等它真的退出）；连点两下会启动两个进程抢同一个库（要加互斥）。需要的话我可以把脚本思路贴出来。 再次谢谢你把这些数字和验证过程写清楚。

[PerryLink]

Checked the recovery path in source. The rename comes from the dialog's third button, not from the failed launch itself.

apps/desktop/src/fatal-recovery.ts:79-121 builds exit / restart / disable-third-party-plugins, with cancelId: 0 and defaultId: 1; only response === 2 calls operations.disablePlugins(). That lands on apps/desktop/src/project-manager.ts:76, sanitizeProfile('dsh', profile, WEB_PROFILE.bundles), and WEB_PROFILE.bundles is ['@deepseek-ai/dsh-base', '@deepseek-ai/dsh-web-app'] (packages/util/official-bundles/src/bundles.ts:14-16) — exactly the 2 you observed.

What sanitizeProfile does (packages/boot/app-boot/src/profile-sanitize.ts:18-38): rename cordis.patch.yml to .bak-<ms> (ordinal suffixes on collision), rewrite dsh.profile.bundles, preserve installed packages and every other manifest field, never parse patches. Next launch's profile init recreates an empty patch (packages/boot/app-boot/README.md:71), so a missing patch afterwards is expected.

Two things worth correcting in the report:

• If a launch cut 35 → 2 without that button being pressed, it is a different bug and worth its own issue. Escape or the window close maps to cancelId 0 (exit), and Enter maps to restart, so neither can reach the recovery write.
• The old bundle list is not backed up anywhere — writeProfileBundles overwrites package.json in place (packages/boot/app-boot/src/profile-plugins.ts). Only the patch file survives in .bak-<ts>. Your snapshot save is what makes the 35-entry list recoverable; without one it has to be rebuilt by hand.

[DSE0131]

Sorry for the false report. I pressed the third button on the recovery dialog — "disable third-party plugins" — and didn't connect it to the bundle list being rewritten. Your trace is correct and this is user error on my side, not a bug. What's on disk here matches it: the leftover backup is cordis.patch.yml.bak-1793240957627, 217 bytes, i.e. the empty template, and 1793240957627 decodes to 2026-10-29T02:28:56Z (10:28:56 local), exactly when I was in that dialog. Esc and Enter couldn't have reached that write. Sorry you had to read the source for an answer that shouldn't have needed it. Two things back: - You're right that the old bundle list has no copy anywhere. What saved us was &nbsp; an unrelated package.json snapshot from an earlier plugin install; without it &nbsp; the 35 entries would have had to be retyped by hand. I worry the next person &nbsp; who presses that button will file the same "plugins vanished" bug, so keeping &nbsp; the previous bundles next to the patch .bak would make it recoverable by &nbsp; anyone, not only by whoever happened to take a snapshot. - If it's cheap: is the prompt explicit that this rewrites the profile's bundle &nbsp; list and does not come back on the next launch? That's the part I got wrong. Closing this as user error on my side. Thanks for reading the source instead of pointing me at the docs.

[elegant01]

Adding a Windows datapoint on 0.2.1-rc.5, plus one correction to a detail above.

Confirms on Windows / rc.5 too. Same numbers as the report: 71 dsh-auth-* cookies, all host_key='127.0.0.1', all path=/, all distinct names, all unexpired (30-day), mean serialized size 226 B (name 52 + value 173 + ; 2) = 16,186 B. So this is not macOS-specific, and not rc.3-specific — rc.5 behaves identically.

Exact threshold from the launch sequence. Two consecutive launches on this machine bracketed it precisely:

cookies before launch	outcome
69 → mints 70th	handshake succeeded (UI rebuilt)
70 → mints 71st	failed 4 s later, desktop welcome: Web authentication failed

Isolated the two halves the same way others did: authenticateWebHost (Node fetch, sends no cookies) returns 303 + set-cookie every time, so the Host is healthy; only the following net.fetch welcome call, which carries the Chromium jar, fails. Manually launching the host with the desktop's own argv prints dsh web: http://127.0.0.1:PORT/?token=… and loads every plugin normally, which rules the config out. One cookie + realistic Chromium navigation headers → 200; 68+ → 431.

Correction: the count does not keep growing after the first failure. Comment above says "失败本身还会再写入一个 Cookie，让问题持续加重". On this machine it is the opposite — it freezes:

• newest cookie created 05:56:38 UTC; first crash 05:56:42 UTC (4 s later)
• five failed launches since: 05:56:42, 05:57:05, 06:02:37, 06:09:02, 06:16:36
• cookies still exactly 71, newest still 05:56:38

The 431 is produced before authorizeIndex can mint anything, so a failing launch cannot add a cookie. Practical consequences: it is a hard wall, not a runaway; retrying the launch is free; and a regression test can assert the count is bounded (stays at N) across N failed launches, not merely that startup fails.

On suggested fixes. Agree with the jar-boundary conclusion. One caveat for option "key the name by host only": on upgrade, legacy cookies keyed by the old sha256(authority) will not match the new key and will linger for the full 30 days — a write-time sibling purge of dsh-auth-* (or a one-shot migration sweep) is needed, otherwise upgraded installs can still hit 431 with a fixed build.

Also worth folding into diagnostics: surfacing the real status (431) instead of collapsing it to Web authentication failed would have made this a five-minute triage. Current wording points every reporter at reinstall/auth first.

No raw cookies, tokens, or the cookie DB included. Happy to re-run a launch loop against a patched build on Windows if useful.

[PerryLink]

Short answer: no.

The button is the only place the action is named — apps/desktop/src/locale.ts:73 (and :253 in Chinese): "Disable third-party plugins, back up profile patch, and restart". The dialog body is fatalSummary (:60) plus dialogDetail(...) (fatal-recovery.ts:35-42), which is the last eight lines of the error, the crash-report path, and the reinstall advice. Neither says dsh.profile.bundles is rewritten, and neither says the previous list will not come back.

What the code actually does, for the record: project-manager.ts:76 → sanitizeProfile('dsh', profile, WEB_PROFILE.bundles); profile-sanitize.ts:18-38 renames the patch to .bak-<ms> and rewrites the bundle list in place via writeProfileBundles. So yes — your reading matches, and the label describes the effect rather than the mechanism.

If one thing changes in a follow-up, the label plus one line in dialogDetail naming the rewrite would cover it; that is cheaper than teaching everyone the .bak-<ts> trick after the fact.

On @elegant01's bracket: the server is createServer (packages/host/webserver/src/index.ts:566) and nothing in the tree overrides maxHeaderSize (grep is empty), so Node's 16 KiB default stands — 70 cookies at ~226 B plus normal navigation headers crossing it at 71 is consistent with the measurement.

And thanks for checking the timestamp yourself, 1793240957627 matching the dialog moment is a better witness than anything I could read from source.