[Bug] 桌面端 0.2.1-rc.5：每次启动铸一枚带随机端口的 dsh-auth-* cookie，约 70 次后 Cookie 头达 16 KB → HTTP 431 → 误报 desktop welcome: Web authentication failed，且无法自愈

[CBEdwin]

[Bug] 桌面端 0.2.1-rc.5：每次启动铸一枚带随机端口的 dsh-auth-* cookie，约 70 次后 Cookie 头达 16 KB → HTTP 431 → 误报 desktop welcome: Web authentication failed，且无法自愈

摘要

@deepseek-ai/dsh-desktop 每次启动都会给 127.0.0.1 铸一枚有效期 30 天、名字里含随机端口的认证 cookie。Chromium 的 cookie 库按 host 隔离、不按端口隔离，因此每条新 cookie 都不会覆盖旧的，只会净增。累计到 71 条时 Cookie: 头约 16,023 B，叠加其余请求头后越过 Node 默认 maxHeaderSize = 16384，Host 在进入任何鉴权代码之前直接返回 431；壳层把任何非 2xx 统一翻译成 Web authentication failed，用户看到的却是"认证失败"。

本文在 0.2.1-rc.5（当前 nightly）上实测复现——已有报告为 rc.2 / rc.3，说明该缺陷跨越了多个版本仍未修复。本机按约 6 次/天的启动频率，约 12 天复发一次。

环境

项目	值
应用	@deepseek-ai/dsh-desktop 0.2.1-rc.5（nightly 通道，app-update.yml 中 channel: nightly）
Electron / Node	44.7.0 / 24.21.0
操作系统	Windows，win32 x64
安装位置	%LOCALAPPDATA%\Programs\DeepSeek Harness（打包版，resources/app.asar）
userData	%APPDATA%\@deepseek-ai\dsh-desktop
第三方插件	已装 30 个 bundle —— 已证明与本故障无关，见"排除项"

现象

DeepSeek Harness is unavailable
The application could not start or stopped unexpectedly.
desktop welcome: Web authentication failed

崩溃报告（logs\crash-2026-10-30T11-53-10-841Z-host.log）：

phase: startup
app: @deepseek-ai/dsh-desktop 0.2.1-rc.5

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)

对话框里的 Restart 与 Disable third-party plugins, back up profile patch, and restart 全部无效；renderer console 无任何 error 级输出。

时间线（2026-10-30，UTC）

时间	事件
08:47:48	最后一次成功启动（~/.dsh/logs/dsh-prompt/*.log 出现 app.boot）
09:01:01	最后一条 dsh-auth-* 被写入（第 71 条）
09:01:03 … 12:27:07	连续 8 次启动失败，崩溃报告逐字相同
之后	越过阈值后，8 次启动一条新 cookie 都没有写入

失败时刻的 cookie 库（Network\Cookies，SQLite）：

行数: 71   host_key: 127.0.0.1（全部）   name: ^dsh-auth-（全部）   其他 cookie: 0
name 长度: 52 B（恒定）   value 长度: 171–173 B
sum(name + value + 2) = 16,023 B ≈ 15.65 KiB（仅 Cookie 头）
创建时间跨度: 2026-10-18T08:36:52Z → 2026-10-30T09:01:01Z（71 条 / 12.0 天 ≈ 5.9 次启动/天）

一旦请求头越界，第一个请求就在解析阶段被拒，那个本应下发新 cookie 的 303 根本不会发生——cookie 库只增不减，无法自愈。这解释了为什么"重试"永远无效，以及为什么它会变成不可恢复的状态。

根因

1. dsh-desktop-host/lib/index.js:342 —— Host 用 ctx.connection.authenticatedUrl(...) 上报 URL，而 Host 以 --port 0 启动，端口每次随机。
2. dsh-client-connection/lib/index.js:440 —— authenticatedUrl() 追加进程级 launchToken。
3. …/index.js:458 authorizeIndex() —— token 命中后返回 303 + Set-Cookie，cookie 由 sessionCookie(cookieName(authority), …) 生成。
4. …/index.js:335 —— cookieName(authority) = "dsh-auth-" + base64url(sha256(authority))，而 authority = url.host，包含临时端口。
5. …/index.js:347 —— Max-Age=2592000（30 天）、HttpOnly、SameSite=Strict、Path=/。
6. Chromium 以 host 为键存储 cookie，不区分端口 → 每次启动都生成一个新名字，旧值既不被覆盖、也不会在 30 天到期前被清除。
7. …/index.js:546 isAuthenticated() 本来就会校验 payload.authority 与请求是否一致——也就是说，名字里带端口并未提供任何额外安全性，只带来了累积。
8. Host 是 Node HTTP 服务，默认 maxHeaderSize = 16384 → 在鉴权逻辑之前返回 431 Request Header Fields Too Large。
9. 壳层把任何非 2xx 折叠成同一句话：

const authenticated = await send(authenticatedUrl, { credentials: "include" });
if (!authenticated.ok) throw new Error("desktop welcome: Web authentication failed");

还有一条让排查更困难的不对称性：authenticateWebHost() 用的是不带 cookie jar 的 Node fetch（永远拿到 303），而 connectDesktopWelcome() 用 net.fetch(..., {credentials:"include"})（带上整包 cookie）——同一个 URL，两条路径行为完全不同，日志里看不到状态码。

复现方法（最小化，无需图形界面自动化）

第一步：证明 Host 侧是健康的（直接 fork 宿主入口，不开任何窗口）

fork(`${RES}/app.asar/dsh/node_modules/@deepseek-ai/dsh-desktop-host/lib/index.js`,
     [RUNTIME, PROJECT, PRIMARY_RUNTIME],
     { cwd: PROJECT, execPath: EXE, execArgv:["--expose-internals"],
       env:{...process.env, ELECTRON_RUN_AS_NODE:"1"}, stdio:["ignore","pipe","pipe","ipc"] });
// 从 IPC {type:"ready"} 取 url
// GET url（redirect:"manual"）        → 303 + Set-Cookie
// 带该 Cookie 再 GET url              → 200

实测：303 / 200 / 不带 cookie 时 401 —— Host 侧完全正确。

第二步：对壳层 cookie 库做 A/B（30 行 Electron 主进程，调用与壳层完全相同的语句）

const r = await net.fetch(url, { credentials: "include" });   // 与 main.js:8884 同一调用

userData	net.fetch 结果	该 origin 下 cookie 数
全新空目录	200	1
真实 userData 的副本	431	71
真实 userData 执行 DELETE FROM cookies WHERE name LIKE 'dsh-auth-%' 之后	200	1

第三步：真实应用验证 —— 清理后启动，~/.dsh/logs/dsh-prompt/*.log 出现 app.boot，工作区正常渲染，此后零崩溃报告。

排除项

• 第三方插件：把 dsh.profile.bundles 缩减为 ["@deepseek-ai/dsh-base","@deepseek-ai/dsh-web-app"] 且清空 cordis.patch.yml 后重试，故障现象完全相同（同一行、同一文案）。插件不是原因。
• 账号 / 凭据 / 代理 / 网络：authenticateWebHost() 每次都成功（否则会抛另一条错误）；失败的是纯本机 127.0.0.1 请求。
• 重装应用：app.asar 完好，cookie 库在 userData 里，重装会保留那包超限的 cookie。
• 浏览器端 dsh web：绑定固定端口时不复现——cookie 名稳定，每次覆盖同一行。

建议修法（按性价比排序）

1. 握手前清理（改动最小，且能修好已损坏的机器）：在 DesktopHostProcess.start() 中、connectDesktopWelcome() 之前遍历 session.defaultSession.cookies，删掉 127.0.0.1 / localhost 上所有匹配 ^dsh-auth- 且不等于本次 token 的项，jar 恒为 1 条。
2. cookie 名不要带端口：改为 dsh-auth- + hash(归一化 host)（或直接用常量名），把完整 authority 留在签名载荷里——isAuthenticated() 已能通过 payload.authority 拒绝跨端口复用，无需靠"名字不同"做隔离。
3. 抬高上限 + 自愈：Host 端 http.createServer({ maxHeaderSize: 64 * 1024 })；并且捕获 431 后清理本地认证 cookie 重试一次，而不是让启动直接失败。
4. 持久化 secret：代码里已有 credentialKey("client-connection","browser-session") 这样的落点；secret 稳定后 cookie 值稳定、名字稳定，覆盖逻辑自然生效。
5. 报错带上状态码：Web authentication failed (HTTP 431)。这一条是本缺陷里最贵的成本来源——现有报告几乎都在这句话上走偏过。

用户侧临时规避

1. 完全退出桌面版（确认任务管理器里没有 DeepSeek Harness 进程——cookie 库在运行时被独占）。
2. 备份 %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies。
3. 执行 DELETE FROM cookies WHERE host_key='127.0.0.1' AND name LIKE 'dsh-auth-%';（或直接删掉该文件，库里没有别的内容）。
4. 重新启动，会重新下发 1 枚 cookie，恢复正常。

本文相对 #9924 / #10632 / #10802 / #10828 / #10830 的增量

• 确认该缺陷延续到 0.2.1-rc.5，即 rc.2 / rc.3 之后并未修复。
• 给出精确量化：71 行、Cookie: 头 16,023 B，并用真实创建时间算出复发周期（约 12 天，约 6 次启动/天）。
• 记录了一个此前未被提及的关键现象：越过阈值后不再有任何新 cookie 被写入——请求在第一跳就被拒，303 不再发生，因此失败是单调的、不可能自愈，这解释了"重试无用"。
• 提供一套 30 行、无需图形界面的复现脚本，可把"Host 侧"与"壳层 cookie 库"彻底分离验证。
• 通过"禁用全部第三方 bundle"证明与插件无关。

---

附录

附录 A：崩溃报告全文

路径：%APPDATA%\@deepseek-ai\dsh-desktop\logs\crash-2026-10-30T11-53-10-841Z-host.log
（路径中的用户名已脱敏为 <user>，其余原文未改动）

time: 2026-10-30T11:53:10.841Z
source: host
phase: startup
app: @deepseek-ai/dsh-desktop 0.2.1-rc.5
platform: win32 x64
electron: 44.7.0
node: 24.21.0
locale: en
shell pid: 16896

--- error ---
Error: desktop welcome: Web authentication failed
    at connectDesktopWelcome (file:///C:/Users/<user>/AppData/Local/Programs/DeepSeek%20Harness/resources/app.asar/lib/main.js:8886:31)
    at async Object.start (file:///C:/Users/<user>/AppData/Local/Programs/DeepSeek%20Harness/resources/app.asar/lib/main.js:12195:22)
    at async file:///C:/Users/<user>/AppData/Local/Programs/DeepSeek%20Harness/resources/app.asar/lib/main.js:7162:5
    at async file:///C:/Users/<user>/AppData/Local/Programs/DeepSeek%20Harness/resources/app.asar/lib/main.js:12313:4

--- renderer console (error level, oldest first) ---
(no error-level renderer console output was captured)

三点值得注意：

1. phase: startup —— 失败发生在启动阶段，尚未进入主窗口。
2. source: host —— 报告由壳层以 host 名义写出，但真正抛错的是壳层自己（lib/main.js:8886），Host 进程并未崩溃。
3. (no error-level renderer console output was captured) —— 渲染进程根本没起来，所以这里永远是空的；这也解释了为什么只看这份日志无从判断"到底是哪一步失败"。

附录 B：同批次崩溃报告清单

%APPDATA%\@deepseek-ai\dsh-desktop\logs\ 下现存 10 份（应用自身有保留上限，更早的 2 份已被回收）：

#	文件名时间戳（UTC）	本地时间（UTC+8）	说明
1	2026-10-30T11-53-10-841Z	19:53:10	用户首次报告
2	2026-10-30T12-08-45-061Z	20:08:45
3	2026-10-30T12-26-46-916Z	20:26:46	连续重试
4	2026-10-30T12-26-51-769Z	20:26:51	连续重试
5	2026-10-30T12-26-56-783Z	20:26:56	连续重试
6	2026-10-30T12-27-03-686Z	20:27:03	连续重试
7	2026-10-30T12-27-07-411Z	20:27:07	连续重试
8	2026-10-30T13-34-38-322Z	21:34:38	排障时主动复现（带 --log-net-log 启动）
9	2026-10-30T13-35-36-243Z	21:35:36	排障时主动复现
10	2026-10-30T13-37-12-484Z	21:37:12	排障时主动复现

关键证据：对全部 10 份做 diff 比对，只有 time: 与 shell pid: 两行不同，其余 17 行逐字一致。示例（11:53 与 12:27:07）：

1c1
< time: 2026-10-30T11:53:10.841Z
---
> time: 2026-10-30T12:27:07.411Z
9c9
< shell pid: 16896
---
> shell pid: 12944

即：每次启动都以完全相同的方式、在完全相同的代码行失败，shell pid 每次都变（新进程）、错误不变——这不是偶发，也不是某个进程状态问题。

另有 09:01:03 与 09:01:19（UTC）的两份报告，内容与此完全相同，已被应用自身的报告保留策略回收。当天最后一次成功启动是 08:47:48，第一次失败是 09:01:03，间隔 13 分钟——这期间正是 dsh-auth-* 从 70 条跨到 71 条的时刻。

附录 C：Cookie 库统计结果

库文件：%APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies（SQLite，53,248 B）
统计对象：故障发生时刻的备份 Cookies.bak-20261030-213903

C.1 总量与体积

指标	值
总 cookie 条数	71
host_key	全部 127.0.0.1（库内没有其他任何 cookie）
name	全部匹配 ^dsh-auth-
name 长度	恒 52 B（dsh-auth- 9 B + base64url(sha256) 43 B）
value 长度	171 B × 47 条 ，173 B × 24 条（差 2 B 为载荷内时间戳位数差异）
单条平均占用	≈ 226 B（含 name=value; 分隔）
Cookie: 头合计	16,023 B ≈ 15.65 KiB
Node 默认 maxHeaderSize	16,384 B
剩余给其他请求头的空间	≈ 361 B（Host、Accept、Accept-Encoding、请求行等很快吃满）

C.2 属性完全一致

is_secure=0, is_httponly=1, samesite=2(Strict), path='/', 条数=71

说明这些 cookie 是同一段代码、同一套属性批量铸出来的，不存在"某一条坏了"的可能——纯粹是数量问题。

C.3 值格式

所有 value 均以 v1. 开头，即 encodeCookie() 的 browser-session 载荷格式：

v<version>.<base64url(payload)>.<base64url(hmac-sha256)>

且 encrypted_value 长度全为 0、明文写在 value 列（这条 Chromium 会话未启用 DPAPI 加密），因此可以直接用 SQL 读出统计。

C.4 按日新增（13 天，合计 71 条）

日期（UTC）	新增	日期（UTC）	新增
2026-10-18	7	2026-10-25	1
2026-10-19	17	2026-10-26	3
2026-10-20	5	2026-10-27	8
2026-10-21	8	2026-10-28	1
2026-10-22	7	2026-10-29	3
2026-10-23	5	2026-10-30	4（当日仅 4 次成功铸入，之后被 431 阻断）
2026-10-24	2

平均 5.9 次/天，跨度 12.0 天（2026-10-18T08:36:52Z → 2026-10-30T09:01:01Z）。10-19 的 17 条对应当天密集安装/切换插件的多次重启。

C.5 首尾样例

创建时间（UTC）	name	value
2026-10-18T08:36:52.675Z	dsh-auth-0exPercdGwj1vnIcTz9SFcRTWGd-owEQNWZc8Ax73_0	173 B
2026-10-18T08:41:35.070Z	dsh-auth-SqQMDV9ACOKRWWm9oJzAZHtOBEZ_fIRBHbz77tVeooE	173 B
2026-10-18T08:49:26.686Z	dsh-auth-dIScBybrqDd17QaVHNs4IijZAav-ZrPC-dWc3NCmeP4	171 B
…	…	…
2026-10-30T08:36:49.144Z	dsh-auth--XizqJn4VHloCOZJuBPt5LObyYXRUGrmZjVoWK47Jpc	171 B
2026-10-30T08:47:50.985Z	dsh-auth-Rc_9upccycBk0L9s1NrLz3pyvMrkezVzP7ZAQfhDchU	171 B
2026-10-30T09:01:01.832Z	dsh-auth-6lxpYm4Xw8MqNCb12F2ovt5EZlIYaN05vLs8eUVXifk	173 B

最后一条（09:01:01.832Z）之后，连续 8 次启动没有再写入任何一条——因为第一个请求在头部解析阶段就被 431 拒绝，那个会下发 cookie 的 303 从未发生。这是"不可自愈"的直接证据。

C.6 复现前后的对照

状态	net.fetch(url,{credentials:"include"})	该 origin 下 cookie 数
全新 userData	200	1
真实 userData（故障态）	431	71
真实 userData（DELETE FROM cookies WHERE name LIKE 'dsh-auth-%' 之后）	200	1

C.7 自查用 SQL

其他用户可用以下语句确认是否为同一问题（须先完全退出应用，该库在运行时被独占）：

-- 1) 看条数与总字节：接近或超过 16000 即为本文所述情形
SELECT count(*) AS rows,
       sum(length(name) + length(value) + 2) AS cookie_header_bytes
FROM cookies
WHERE host_key = '127.0.0.1' AND name LIKE 'dsh-auth-%';

-- 2) 看时间跨度与增长速度
SELECT date(creation_utc/1000000 - 11644473600, 'unixepoch') AS day, count(*) AS minted
FROM cookies WHERE host_key = '127.0.0.1'
GROUP BY day ORDER BY day;

-- 3) 修复（先备份文件）
DELETE FROM cookies WHERE host_key = '127.0.0.1' AND name LIKE 'dsh-auth-%';

[DIYWHLJ]

同机独立复现（Windows 10.0.26220 · @deepseek-ai/dsh-desktop 0.2.1-rc.5 · Electron 44.7.0 / Node 24.21.0），补充三组主帖未覆盖的证据：

1. 用与壳完全相同的参数手工拉起 Host，对同一 launch URL 做对照

请求形态	结果
fetch(url, { redirect: 'manual' })（Node，不带任何 cookie，即壳里 authenticateWebHost 的形态）	303 + Set-Cookie
同一 URL 跟跳转、但无 cookie jar（即 net.fetch 在 cookie 未命中时的形态）	401
带 ~8,000 B Cookie 头	200
带 ~16,000 B / ~16,400 B Cookie 头	431（响应体为空）

结论：authenticateWebHost 用 Node fetch 永远成功（它根本不发 cookie），失败只发生在壳层第二次 net.fetch(authenticatedUrl, { credentials: "include" })——71 条历史 cookie 使请求头越过 Node 默认 maxHeaderSize = 16384，Host 在进入任何鉴权代码之前就回 431，壳层统一译成 Web authentication failed。这也解释了为什么日志里看不到任何 Host 侧报错。

2. 修复验证

备份 Network/Cookies 后执行主帖给的语句：

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

重启后窗口正常进入（插件更新流程），无新 crash 日志；下一次启动只新增 1 条，Cookie 头回到几百字节。

补充：应用运行时该库被独占，SQLite 以 readOnly 打开也会 SQLITE_CANTOPEN，必须先完全退出应用再操作。

3. 建议修复方向（任选其一，前两条最彻底）

• cookie 名不要编码 authority/端口（改成固定名），让同 host 的新 cookie 覆盖旧的，而不是净增；
• 或 mint 新 cookie 前主动删除同 host 下旧的 dsh-auth-*（位置就在 authorizeIndex 下发 Set-Cookie 处）；
• 或 Host 启动时清理自身历史 cookie；
• 壳层把非 2xx 的具体状态码写进错误信息（431 不应与“凭据错误”共用一句 Web authentication failed），至少让用户/日志能一眼分流。

主帖的自查 SQL 很好用，本机按同样方法确认 71 条、Cookie 头共 16,088 B。

[paozai2321]

补充一组实测数据，给修这个问题的人参考。

1. 二分钉死的阈值（不是估算）

自建本地服务做二分探测：

• 最小头开销：cookie 头 ≤16165 B → 303；≥16166 B → 431
• Chromium 完整头开销下：阈值 15951 B
• 当时真实罐 16168 B，两种开销下都越界

（第一轮我用估算得出「超限 42 字节」，实测却返回 303 成功——因为 Node 限的是整个请求字节数（含请求行），不是仅头部块。所以估算会错，得实测。）

2. 时间咬合

第 71 个 cookie 签发于 19:29:49，首次崩溃于 19:29:49.148 —— 同一秒。

3. 一个缓解时容易踩的坑

在 profile 的 cordis.patch.yml 里追加：

- id: connection
  name: @deepseek-ai/dsh-client-connection
  config:
    trustedHosts: !!js ctx.webStartup.trustedHosts
    cookieMaxAgeDays: 1

patch 对 config 是整体替换、不是字段合并——只写 cookieMaxAgeDays 会让 bundle 层的 trustedHosts 静默消失。所以两个字段都要重述。

另外注意 loader 条目 id ≠ 插件名：条目 id 是 connection，插件名是 @deepseek-ai/dsh-client-connection。直接猜成 client-connection 会造出一个幽灵条目。

4. 缓解后的已知代价

cookieMaxAgeDays: 1 意味着连续开机超过 1 天的会话需要重启一次重新铸造。换成 2 天的话，按本机日均 15 次、峰值 21 次启动算，2 天峰值 42 个、余量 40%；3 天只剩 10%、4 天必复发。

5. 一个连带的坑，可能值得单开一条

这个 431 崩溃会触发 sanitizeProfile()，把用户的 cordis.patch.yml 改名成 .bak-<epoch毫秒>，下次启动重建空模板。所以用户遇到的是一个复合事故：启动失败 + 配置被静默清空。而且「配置被清空」看起来像原因，实际是结果——我因此排查了很久错方向。

如果这条还没人报，我可以单独整理一份。——来自一条鱼

[bysdxt]

一样的报错/问题

crash-2026-10-30T15-39-52-565Z-host.log
crash-2026-10-30T15-40-14-330Z-host.log

点disable and restart也一样