[Bug] Desktop "Web authentication failed": stale dsh-auth-* cookies overflow the Host header limit (431)

[Mooling0602]

Environment

• dsh: 0.2.1-alpha.4 (git 86a4022); the same code is still present on dsh-v0.2.1-alpha.5 and dsh-v0.2.1-rc.1
• Linux x64 (NixOS, Wayland), Electron 44.3.0, Node 24.20.0
• Launch path: the packaged Desktop app (apps/desktop), not dsh web
• External plugins in the Desktop profile, versions as resolved in node_modules (listed for completeness; the failure is an HTTP-layer cookie overflow and does not depend on the plugin set):
  • @changfenhuang/dsh-genui 0.12.0
  • @linxin666/dsh-client-ui-git-graph 0.4.6
  • @michengai/dsh-archive-manager 1.0.19
  • @michengai/dsh-btw 0.1.24
  • @michengai/dsh-code-review 0.1.16
  • @michengai/dsh-skills-manager 1.1.21
  • @xmanrui/dsh-im 4.39.0
  • ds-bot 0.1.6
  • dsh-better-sidebar 0.26.0
  • dsh-context 0.72.0
  • dsh-univer-office 0.3.7
  • dsh-web-file-uploader 0.4.3 (github:Mooling0602/dsh-web-file-uploader@8f8fe5c)
  • dsh-whale-widget 0.4.2
  • dshmarket 1.66.22

Symptom

The Desktop window fails to open and shows:

Error: desktop welcome: Web authentication failed
    at connectDesktopWelcome (.../welcome-backend.ts:51)

The Host itself starts fine and prints its URL:

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

and that exact URL answers 303 See Other with a valid set-cookie when requested with curl, so authentication code and Host are healthy.

Crash Logs

crashlog-dsh-desktop.zip

• netlog-failing-launch.json — Chromium netlog of one failing launch, captured with --log-net-log. The launch token and all 71 cookie values are replaced by same-length filler, so every byte count below is unchanged. It shows:
  • GET /?token=<redacted> HTTP/1.1 against http://127.0.0.1:42779
  • one Cookie header of 16194 bytes (16186 bytes of value plus the Cookie: prefix) carrying 71 dsh-auth-* cookies
  • the response HTTP/1.1 431 Request Header Fields Too Large

Root cause

Durable session cookies accumulate on every launch until the request header exceeds the Node HTTP server's default 16 KiB limit:

1. The Desktop Host binds a random port — args: ['--no-open', '--host', '127.0.0.1', '--port', '0'] (apps/desktop-host/src/index.ts:30).
2. The session cookie is named after the request authority, which for plain HTTP includes the port — cookieName() returns dsh-auth- + sha256(authority) (packages/client/connection/src/browser-auth.ts:116). A new port therefore produces a new cookie name.
3. The cookie is long-lived: cookieMaxAgeDays defaults to 30 (packages/client/connection/src/index.ts:115), emitted as Max-Age=2592000 by sessionCookie().
4. The Electron default session persists it in the app cookie store (~/.config/@deepseek-ai/dsh-desktop/Cookies), and the Desktop shell never removes any — apps/desktop/src contains no cookies.remove.
5. Chromium sends every cookie whose domain matches 127.0.0.1 regardless of port, so each launch stacks one more cookie onto the same request.
6. Once the combined Cookie header pushes the request past the 16 KiB header limit, the Host replies:

HTTP/1.1 431 Request Header Fields Too Large

7. connectDesktopWelcome() maps any non-2xx response to an authentication failure (apps/desktop/src/welcome-backend.ts:51), so a healthy Host plus an oversized header surfaces as "Web authentication failed". The dialog never mentions 431.

Evidence

• The cookie store held 71 rows named dsh-auth-* for host 127.0.0.1 — one per launch, the oldest about 30 days old.
• A Chromium netlog of a failing launch shows the /?token=… request carrying all 71 cookies, a 16186-byte Cookie header, and the response HTTP/1.1 431 Request Header Fields Too Large.
• Deleting those 71 cookies resolves it on an otherwise unchanged build: no Web authentication failed, the window opens, the model list loads.
• The limit is reachable through ordinary use: at ~230 bytes per cookie, ~70 launches fill the 16 KiB budget.

Recovery (user side)

With the app closed:

import sqlite3, os
p = os.path.expanduser('~/.config/@deepseek-ai/dsh-desktop/Cookies')
c = sqlite3.connect(p)
c.execute("delete from cookies where name like 'dsh-auth-%'")
c.commit()

Clearing the app's site data works too. Either way it returns after roughly the same number of launches.

Suggested fixes

Any one of these breaks the chain:

1. Prune before the handshake — most targeted. In main() immediately before connectDesktopWelcome, remove cookies whose name starts with dsh-auth- for the Host URL; the token in ready.url mints this launch's cookie anyway, so earlier ones are dead weight.
2. Raise the listener limit — create the Host listener with a larger maxHeaderSize so accumulation cannot break startup.
3. Key the cookie by host instead of authority, or cap the number of live session cookies, so a random port does not create a new cookie per launch.
4. Shorten cookieMaxAgeDays on the Desktop path — reduces the window but does not remove the failure mode.

Notes

This is not specific to any downstream packaging: the random port, the authority-keyed name, the 30-day lifetime and the absence of cleanup all live in upstream code, and both dsh-v0.2.1-alpha.5 and dsh-v0.2.1-rc.1 still carry them unchanged.

Downstream packaging reference

For reference, the build that reproduced this is packaged in
Mooling0602/nix-packages:

• pkgs/by-name/de/deepseek-harness-desktop/ — the Desktop package (Electron shell assembly plus the Linux shell patches)
• pkgs/by-name/de/deepseek-harness-git/ — the upstream source pin (hashes.json: 0.2.1-alpha.4, rev 86a4022)

Those patches only add Linux shell behaviours (tray icon, menu bar visibility, SIGINT/SIGTERM shutdown, window glass). They never touch the Host port, the cookie names, the cookie lifetime, or the session cookie jar — which is why this report carries no downstream patch and the defect reproduces against the unpatched upstream bundle.

Happy to test a patch if you would like a specific approach.

[Mooling0602]

@MoolingBot 翻一份中文版到这里以供参考

[MoolingBot]

收到，我来把这份报告翻译成中文贴在这里。

[MoolingBot]

环境

• dsh: 0.2.1-alpha.4（git 86a4022）；同样的代码在 dsh-v0.2.1-alpha.5 与 dsh-v0.2.1-rc.1 上依然存在
• Linux x64（NixOS，Wayland）、Electron 44.3.0、Node 24.20.0
• 启动方式：打包后的 Desktop 应用（apps/desktop），而不是 dsh web
• Desktop profile 中的外部插件，版本按 node_modules 里的解析结果（仅为完整性列出；故障是 HTTP 层的 Cookie 溢出，与插件集合无关）：
  • @changfenhuang/dsh-genui 0.12.0
  • @linxin666/dsh-client-ui-git-graph 0.4.6
  • @michengai/dsh-archive-manager 1.0.19
  • @michengai/dsh-btw 0.1.24
  • @michengai/dsh-code-review 0.1.16
  • @michengai/dsh-skills-manager 1.1.21
  • @xmanrui/dsh-im 4.39.0
  • ds-bot 0.1.6
  • dsh-better-sidebar 0.26.0
  • dsh-context 0.72.0
  • dsh-univer-office 0.3.7
  • dsh-web-file-uploader 0.4.3（github:Mooling0602/dsh-web-file-uploader@8f8fe5c）
  • dsh-whale-widget 0.4.2
  • dshmarket 1.66.22

现象

Desktop 窗口打不开，并显示：

Error: desktop welcome: Web authentication failed
    at connectDesktopWelcome (.../welcome-backend.ts:51)

Host 进程本身启动正常，并打印了 URL：

dsh web: http://127.0.0.1:<随机端口>/?token=<token>

而且用 curl 请求这个 URL 会返回 303 See Other 并带上有效的 set-cookie，说明鉴权代码和 Host 都是健康的。

崩溃日志

crashlog-dsh-desktop.zip

• netlog-failing-launch.json —— 用 --log-net-log 抓取的一次失败启动的 Chromium netlog。启动 token 和全部 71 个 Cookie 的值都替换成了等长填充，因此下面每个字节数保持不变。它显示：
  • 对 http://127.0.0.1:42779 的 GET /?token=<redacted> HTTP/1.1
  • 单个 16194 字节 的 Cookie 头（16186 字节的值加上 Cookie: 前缀），携带 71 个 dsh-auth-* Cookie
  • 响应 HTTP/1.1 431 Request Header Fields Too Large

根因

持久化的会话 Cookie 在每次启动时不断累积，直到请求头超过 Node HTTP 服务端默认的 16 KiB 限制：

1. Desktop Host 每次绑定随机端口 —— args: ['--no-open', '--host', '127.0.0.1', '--port', '0']（apps/desktop-host/src/index.ts:30）。
2. 会话 Cookie 以请求的 authority 命名，对明文 HTTP 而言 authority 包含端口 —— cookieName() 返回 dsh-auth- + sha256(authority)（packages/client/connection/src/browser-auth.ts:116）。因此每个新端口都会产生一个新的 Cookie 名。
3. Cookie 生命周期很长：cookieMaxAgeDays 默认为 30（packages/client/connection/src/index.ts:115），由 sessionCookie() 输出为 Max-Age=2592000。
4. Electron 默认会话把它持久化在应用的 Cookie 存储中（~/.config/@deepseek-ai/dsh-desktop/Cookies），而 Desktop shell 从不清理 —— apps/desktop/src 里没有任何 cookies.remove。
5. Chromium 会发送所有域名匹配 127.0.0.1 的 Cookie，与端口无关，于是每次启动都会在同一个请求上多叠一个 Cookie。
6. 当合并后的 Cookie 头把请求推过 16 KiB 头部限制时，Host 就会回复：

HTTP/1.1 431 Request Header Fields Too Large

7. connectDesktopWelcome() 把任何非 2xx 响应都当作鉴权失败（apps/desktop/src/welcome-backend.ts:51），所以「健康 Host + 超长请求头」最终表现为「Web authentication failed」，弹窗里完全不会提到 431。

证据

• Cookie 存储中有 71 条 host 为 127.0.0.1、名为 dsh-auth-* 的记录 —— 每次启动一条，最老的约 30 天。
• 一次失败启动的 Chromium netlog 显示 /?token=… 请求携带了全部 71 个 Cookie，Cookie 头 16186 字节，响应为 HTTP/1.1 431 Request Header Fields Too Large。
• 在其余条件完全不变的构建上删除这 71 个 Cookie 后问题消失：不再出现 Web authentication failed，窗口能打开，模型列表也能加载。
• 这个限制在日常使用中就能触达：按每个 Cookie 约 230 字节计算，约 70 次启动就会填满 16 KiB 的预算。

恢复方式（用户侧）

先关闭应用：

import sqlite3, os
p = os.path.expanduser('~/.config/@deepseek-ai/dsh-desktop/Cookies')
c = sqlite3.connect(p)
c.execute("delete from cookies where name like 'dsh-auth-%'")
c.commit()

清除应用的站点数据同样有效。但无论哪种方式，大约再启动相同次数后问题都会复现。

建议修法

以下任意一条都能打断这条链路：

1. 握手前先清理 —— 最有针对性。在 main() 中、调用 connectDesktopWelcome 之前，删除 Host URL 下所有以 dsh-auth- 开头的 Cookie；本次启动的新 Cookie 由 ready.url 里的 token 重新签发，之前那些都是死重。
2. 提高监听端限制 —— 用更大的 maxHeaderSize 创建 Host listener，使累积不至于破坏启动。
3. 按 host 而非 authority 命名 Cookie，或限制活跃会话 Cookie 的数量，这样随机端口就不会每次启动都产生新 Cookie。
4. 在 Desktop 路径上缩短 cookieMaxAgeDays —— 只能缩小时间窗口，不能消除故障模式。

备注

这个问题不特定于任何下游打包：随机端口、按 authority 命名的 Cookie、30 天有效期以及缺少清理，全都位于上游代码中，且 dsh-v0.2.1-alpha.5 与 dsh-v0.2.1-rc.1 均原样保留。

更新：本次正文已补充崩溃日志（crashlog zip 与 netlog 抓包细节）。

下游打包参考

供参考，复现该问题的构建打包在 Mooling0602/nix-packages：

• pkgs/by-name/de/deepseek-harness-desktop/ —— Desktop 包（Electron shell 组装加 Linux shell 补丁）
• pkgs/by-name/de/deepseek-harness-git/ —— 上游源码 pin（hashes.json：0.2.1-alpha.4，rev 86a4022）

这些补丁只增加了 Linux shell 行为（托盘图标、菜单栏可见性、SIGINT/SIGTERM 退出、窗口毛玻璃），从未触碰 Host 端口、Cookie 名称、Cookie 生命周期或会话 Cookie 存储 —— 这也是本报告不含下游补丁、且该缺陷在未打补丁的上游 bundle 上同样能复现的原因。

如果需要验证某种具体方案，我很乐意测试补丁。

[MoolingBot]

中文版已贴在上面（#discussioncomment-18989912）。内容与原报告一一对应：环境、现象、7 步根因链、netlog 证据（71 个 cookie / 16186 字节 Cookie 头 / 431）、用户侧恢复脚本、四种修法建议，以及下游打包说明。如需我按其中某个方案提交补丁或做验证，随时说。

[Mooling0602]

根据原文的新变化，更新中文翻译内容到你已发布的评论中。

[MoolingBot]

收到，我按正文的最新变化更新中文译文。

[shenjackyuanjie]

https://github.com/dsh-external/issues/issues/619

dsh-external 有了

[Mooling0602]

https://github.com/dsh-external/issues/issues/619

dsh-external 有了

看上去像是内部链接，普通用户访问不了

[Mooling0602]

使用 Pi Agent 在后台进行了一遍分析，实测发现这可能属于严重 bug，我这里根据它的输出结果进行简单总结：

• dsh 桌面版窗口长时间运行时，概率性出现窗口内容全部空白，但内部任务仍然在走，从托盘退出会导致任务中止
• 可能导致下一次无法启动 dsh 桌面版

[Mooling0602]

已在正文部分更新崩溃日志，作为补充。

[MoolingBot]

中文译文已按正文最新变化更新（#discussioncomment-18989912）：补上了外部插件版本清单、新增的「崩溃日志」小节（crashlog zip 与 netlog 抓包要点），并在备注中标注本次更新。其余内容与原报告保持一致。

[141HR]

在 Windows 上确认，且 0.2.1-rc.2 仍然存在（比你核查的 rc.1 更新）。

• dsh 0.2.1-rc.2，构建 commit 332895e0f7c9d4dbfb29729f5eb367fa263ff986，Electron 44.7.0，Node 24.21.0，Windows 11 x64
• 本平台的 Cookie 存储位置是 %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies：71 条，host_key 全为 127.0.0.1，名字全为 dsh-auth-*。仅 name=value 部分合计 16 117 字节，其他头还没算。
• 阈值是实测而非估算：用合成 Cookie 头重放同一个 Host，≤16 200 字节返回 303，≥16 400 字节返回 431。触发点正是 Node HTTP 的 maxHeaderSize 默认值，与 Cookie 内容无关。
• 分层验证（用于排除环境因素）：authenticateWebHost() 走 Node 原生 fetch（无 Cookie 容器、不走代理），正常拿到 303；半秒后 connectDesktopWelcome() 用 net.fetch 请求同一 URL 就得到 431。同一个 host 进程、同一个启动 token。
• 环境同样不是因素：系统代理的绕过列表里包含 127.*，用干净的 Chrome 配置打开同一个 token URL 能完整渲染应用。唯一差异就是 Electron 会话的 Cookie 容器。
• 删除这 71 条 Cookie 后，其余条件不变的构建立刻能启动；此后每次启动又新增一条 —— 与你按约 230 字节/次推算的结论一致。

你建议的第 1 种修法（握手前清理 Host 源下以 dsh-auth- 开头的 Cookie）我认为是最合适的：ready.url 里的 token 本来就会为本次启动重新签发一条 Cookie，累积的那些只会被发送、从不被读取。

另外补一条：connectDesktopWelcome() 里把真实状态码带出来会很有价值。431 目前呈现给用户的是「Web authentication failed」，会被理解成账号或网络问题，直接把用户带进反复重装的循环。

[MoolingBot]

收到，看到 Windows 上 rc.2 的复验结论了。我先核对一下 rc.2 与当前 master 的代码现状，然后把结论补充到这里。

[MoolingBot]

谢谢详尽的复验，Windows 侧那组分层实验（原生 fetch 303 / net.fetch 431，同一 host 进程、同一 token）把「环境因素」彻底排掉了，这比原始报告的净证据力更强。

刚对比了 dsh-v0.2.1-rc.2 与当前 master：apps/desktop/src/main.ts 与 apps/desktop/src/welcome-backend.ts 逐字节相同，packages/host/webserver/src/index.ts 的 createServer(listener) 仍未传 maxHeaderSize，packages/client/connection/src/index.ts:115 的 cookieMaxAgeDays 仍是 30，browser-auth.ts:116 仍按 authority（含端口）算 cookie 名。也就是说 rc.2 之后确实没有任何修复落地，问题在 master 上同样可复现。

在此之上补两点，可能影响修法选择：

1. 桌面壳其实已经持有干净的凭据。 authenticateWebHost()（apps/desktop/src/web-document.ts:43-50）走 Node 原生 fetch，从 set-cookie 里取出 name=value，存进 hostCookie（main.ts:454），随后被 forwardWebRequest 与 webRequest.onBeforeSendHeaders 直接用作 cookie 头（main.ts:679、main.ts:725）。所以 welcome 握手完全不必依赖 Cookie 容器：把 hostCookie 作为显式 headers: { cookie: hostCookie } 传给 connectDesktopWelcome，或者在一个不落盘的 session.fromPartition(..., { cache: false }) 上跑这次握手，就绕开了累积链条 —— 比「握手前先删」更彻底，因为后者每次升级／多窗口仍要重跑清理，而前者从结构上只发送一条 cookie。

2. 同一个溢出还威胁账号 WebSocket。 connectDesktopWelcome 的第三个参数 cookies()（main.ts:458）把 session.defaultSession.cookies.get({ url }) 的全部 cookie 拼成一个 cookie 头，交给 desktopAccountBackend 的 new WebSocket(url, { headers: { cookie } })（apps/desktop/src/account-backend.ts:101-105）。WS 握手同样受 Node maxHeaderSize 约束；即使 welcome 那一步修好，累计到 70 条左右时账号通道会以另一种形式失败（握手被拒，表现为账号一直「重连中」）。所以只修 connectDesktopWelcome 一处不够，cookies() 这个聚合器也得一起收窄到当前 authority 对应的那一条。

3. 关于把状态码带出来：welcome-backend.ts:51 现在丢弃了 authenticated.status。建议改成 throw new Error(\desktop welcome: Web authentication failed (HTTP ${authenticated.status})`)`，并在 431 上追加一句指向 cookie 清理的提示 —— 用户能看到的就只是 welcome 窗口的文案，状态码是唯一能自救的线索。

如果维护者愿意，我可以按第 1 点（显式 hostCookie + 收窄 cookies()）写一版补丁并附测试；authenticateWebHost 已经有现成的 303/set-cookie 断言可以复用。

[MoolingBot]

补充完毕。要点：rc.2 与 master 的 main.ts / welcome-backend.ts 完全相同，修复尚未落地；另外 account-backend.ts:101-105 的 WebSocket 握手复用同一个全量 cookie 聚合器，同样会被 431 打到 —— 收窄它和 welcome 握手两处才够。需要我出补丁或做验证，随时说。

[Mooling0602]

@MoolingBot 停止无休止的对无协作权限项目的持续分析，保存到你的工作区记忆中，无需回复。可以贴个眼睛表情到此消息表示收到。