Desktop startup fails with "Web authentication failed": stale dsh-auth cookies accumulate until HTTP 431

[shiein]

Desktop fails to start with "desktop welcome: Web authentication failed" after ~70 launches

(stale dsh-auth cookies → HTTP 431)

Version: @deepseek-ai/dsh-desktop 0.2.2-rc.1, Electron 44.7.0, macOS arm64

Symptom
Desktop refuses to start; every launch fails with:

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

The crash report lists recent plugin operations, which suggests a plugin cause, but the Host
starts fine with the same profile.

Root cause

• Each launch the Host listens on a random port, and BrowserAuth mints a cookie named
  dsh-auth-<sha256(host:port)> with Max-Age 30 days.
• The cookie domain is 127.0.0.1 and Path is /, so Chromium sends every previous launch's
  cookie on each request; nothing ever removes them.
• The Electron session cookie store had 71 dsh-auth-* cookies → a 16,186-byte Cookie header.
• The Host's Node HTTP server rejects requests whose headers exceed ~16 KiB with 431, and
  connectDesktopWelcome reports any non-OK status as "Web authentication failed".
• Once over the limit, no new cookie is minted, so the failure is permanent until cookies expire.

Reproduction (Host side)
Start the desktop host and request / with a valid auth cookie plus N stale dsh-auth-* cookies
of the real size (name 52 bytes, value 173 bytes):

• Cookie header 16,186 bytes with minimal other headers → 200
• Cookie header 17,326 bytes → 431
• 16,186 bytes plus browser-like headers (User-Agent, sec-ch-ua, …) → 431

Workaround
Quit the app, then delete the stale cookies:

  sqlite3 ~/Library/Application\ Support/@deepseek-ai/dsh-desktop/Cookies \
    "DELETE FROM cookies WHERE host_key='127.0.0.1' AND name LIKE 'dsh-auth-%';"

Suggestions

• Desktop owns its Electron session: clear stale dsh-auth-* cookies for 127.0.0.1 before
  authenticating, or mint session-lifetime cookies for desktop.
• Surface the HTTP status in the welcome error (e.g. "Web authentication failed (431)") instead of
  a generic auth failure.
• Raising maxHeaderSize alone only postpones the failure.

[Tests4gptplay]

补充一例 Windows Desktop 0.2.2-rc.1 的独立实测：仅清理本地 DSH 认证 Cookie 后恢复启动，未禁用或卸载第三方插件。

环境与症状

• 平台：win32 x64，界面语言 zh-CN。
• Desktop：@deepseek-ai/dsh-desktop 0.2.2-rc.1。
• Electron 44.7.0 / Node 24.21.0。
• 2026-11-09 连续两次启动失败，错误均为 desktop welcome: Web authentication failed，堆栈位于打包的 lib/main.js:16856，调用点 20386。
• 发生在一次第三方插件换装后的重启，因此最初误以为是插件故障。操作历史只构成时间背景，不能证明插件致因。

本次实际观察

1. 完全退出 DSH 后，只读检查 Cookie 数据库：host_key='127.0.0.1' AND name LIKE 'dsh-auth-%' 共 71 条，全部未过期。每条名称 52 字节、值 173 字节；拼接 Cookie header value 为 16,186 字节。
2. 该安装包中服务端使用 createServer(listener)；同一 Electron 的 Node 运行时 http.maxHeaderSize 为 16,384。
3. 用同一个已安装 Electron 的 Node 模式启动最小本地 HTTP server，发送等长的虚构 Cookie，不使用任何真实凭据：

Cookie 数量	Cookie header value 字节数	HTTP 状态
0	0	200
71	16186	200
72	16414	431

证据边界：原始崩溃日志没有 HTTP 状态，本次没有抓取真实失败请求的 netlog。上表是最小 HTTP server 的合成请求测试，不应当被解读为已直接捕获该次真实启动请求返回 431。71 条在实际 Chromium 请求中还会叠加其他请求头。

已验证的最小恢复

完全退出 DSH、保存原始数据库备份后，仅执行：

DELETE FROM cookies
WHERE host_key = '127.0.0.1'
  AND name LIKE 'dsh-auth-%';

• 匹配条目：71 → 0；非目标 Cookie 记录保持一致。
• 未修改插件配置、聊天数据或 ChatGPT 独立浏览器分区；未应用 Dots 的宿主持久化补丁，安装程序归档也未修改。
• 再启动 DSH 后，已观察到主界面、会话列表、输入框及 DSH Dots 入口；用户也确认正常打开。
• 原始备份在独立测试副本上回滚可恢复 71 条，且文件 SHA-256 与原始数据库一致。未将回滚数据写回已恢复的正式环境。

这与本讨论所述的 Cookie 累积问题一致。建议在桌面端管理已结束 Host 遗留的认证 Cookie，保留仍在运行实例的认证隔离，并在 welcome 错误中显示实际 HTTP 状态，减少被误判为插件故障的情况。另有 Windows 同类反馈：#12739。

隐私说明：此补充仅包含脱敏后的错误、数量和复现方法；不上传 Cookie 值、启动 token、数据库、回滚备份、账号凭据或聊天内容。

[spartawhy117]

补充一例：Windows 0.2.2-rc.1 —— 71 条未过期的 dsh-auth-* cookie；仅删除这些 cookie 即恢复启动；失败启动还清空了用户的 cordis.patch.yml

摘要

Windows 桌面端 0.2.2-rc.1 连续三次启动失败，错误均为 desktop welcome: Web authentication failed。本机状态与上面描述的根因一致：127.0.0.1 下有 71 条未过期的 dsh-auth-* cookie。只删除这些 cookie（未禁用/卸载插件、未重装、未改配置）后启动立即恢复。另有一条现有报告未覆盖的现象：失败启动过程中，profile 的 cordis.patch.yml 被重写成空数组，用户设置被静默丢弃。

环境

• @deepseek-ai/dsh-desktop 0.2.2-rc.1；Electron 44.7.0；Node 24.21.0（取自崩溃日志头部）
• Windows 11 x64，界面语言 zh-CN
• DSH_HOME = C:\Users\<user>\.dsh，profile 为 desktop
• 已安装第三方插件（如 dsh-file-drag@0.4.0）；恢复过程中未禁用、未移除任何插件

崩溃时间线（本地时间 UTC+8，2026-11-10）

时间	日志文件	错误
15:05:35	crash-...07-05-35Z-web-boot.log	web boot: 4 entries did not activate —— @deepseek-ai/dsh-client-ui-file-drag: failed；ui-chat、ui-attachment、ui-sidebar-documentpreview 因等待服务 fileDrag 而 pending
15:05:52	crash-...07-05-52Z-host.log	desktop welcome: Web authentication failed（app.asar/lib/main.js:16856，经 :20386 调用）
15:05:56	crash-...07-05-56Z-host.log	同一堆栈
15:15:55	crash-...07-15-55Z-host.log	同一堆栈（手动重启后再次发生）

Cookie 实测（只读，应用已完全退出）

数据库：%APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies

SELECT count(*) AS n, sum(length(value)) AS value_bytes
FROM cookies
WHERE host_key = '127.0.0.1' AND name LIKE 'dsh-auth-%';
-- n = 71, value_bytes = 12283

• 71 条全部未过期，每条对应一个历史随机端口。
• name 52 B、value 173 B → 单条头部成本 52 + 1 + 173 + 2 = 228 B → 71 × 228 = 16,188 B，尚未计入其他请求头。加上 User-Agent、sec-ch-ua 等即超过 Node 默认 maxHeaderSize（16,384），与本帖此前给出的 16,186 B 一致。

恢复过程（仅一项改动）

1. 完全退出应用（所有 DeepSeek Harness.exe 进程结束）。
2. 备份 Cookies 及其 sidecar 文件为 Cookies.bak-20261110-071743*。
3. 执行 DELETE FROM cookies WHERE host_key IN ('127.0.0.1','localhost','[::1]') AND name LIKE 'dsh-auth-%'; → 71 → 0 行；数据库体积不变（53,248 B，未执行 VACUUM）。
4. 重新启动 → 之后未产生新的崩溃日志，5 个进程存活，主窗口与界面可用；插件集合未变。

新增副作用：失败启动覆盖了 profile patch

15:05:54（即崩溃 #2 与 #3 之间），%USERPROFILE%\.dsh\profiles\desktop\cordis.patch.yml 被重写为空数组（[]），原内容保留为 cordis.patch.yml.bak-1794294354365。

丢失的条目包括 agent-default-model（provider/model/reasoning effort）、permission presets、ui-settings-account 引导状态、ui-chat、agent-preset-registry 与 ui-theme。本次没有执行 #12502 中那种“Disable third-party plugins”操作。无论该重写是失败启动后的有意“修复”还是误写，对本 bug 的受害者都构成静默数据丢失。

证据边界

• 未抓取真实失败请求的 netlog 或 HTTP 状态码。431 由两点推断：(a) 上述头部字节计算；(b) 仅删除陈旧 cookie 即恢复启动。
• web boot: 4 entries did not activate 来自更早的一次启动（15:05:35），恢复后未复现；是否与本次失败同源尚不明确。
• 本评论不包含任何 cookie 值、启动 token、凭据、数据库转储或聊天内容。

建议

• 桌面端在欢迎握手前清理回环域下陈旧的 dsh-auth-* cookie，仅保留当前会话的那一条。
• 在错误信息中带上真实 HTTP 状态（如 Web authentication failed (431)）——当前通用文案与真正的认证失败无法区分，会引导用户去重装或禁用插件。
• 失败启动时不得重写用户的 cordis.patch.yml；若必须重置，请在界面中暴露备份路径。
• 仅调大 maxHeaderSize 只是把阈值后移。

[renleidedadi]

啊？竟然有网友被削掉了插件配置？这个确实惨，幸好我让ai修的时候在提示词里说明了一下：“记得备份用户配置”，让我自己幸免了