[Desktop] rc.2 / rc.3 均稳定复现：dsh-auth-* cookie 无限累积，约 70 次启动后必然启动失败

[xiaocangdemiao]

[Desktop] 约 70 次启动后必然无法启动：dsh-auth-* cookie 无限累积，Cookie 头超过 16 KB

现象

DSH Desktop 启动即弹窗失败，无法进入主界面：

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

崩溃日志每次都一样（5 次启动，5 份相同日志）：

phase: startup
app: @deepseek-ai/dsh-desktop 0.2.1-rc.2
electron: 44.7.0
Error: desktop welcome: Web authentication failed
    at connectDesktopWelcome (app.asar/lib/main.js:8886:31)
    at async Object.start (app.asar/lib/main.js:12194:22)

与安装路径无关：重装到另一个目录仍然复现。
与插件无关：禁用全部第三方插件仍然复现。

根因

%APPDATA%\@deepseek-ai\dsh-desktop\Cookies 里积累了大量认证 cookie：

cookie 总数: 71
host_key 全部是 127.0.0.1
name 全是 dsh-auth-<52 字符随机>
value 是 v1.<base64 JWT>，每个 173 字符

每次启动新增一个 dsh-auth-*，从不清理。

实测请求头：

Cookie 头总长: 16,188 字节 (15.8 KB)
最早: 2026-10-22 03:05
最晚: 2026-10-28 14:36   （6 天 71 次启动）

为什么只失败在第二步

主进程启动时连续做两件事，用的是两个不同的 HTTP 客户端：

// 1) app.asar/lib/main.js — 用 Node 的 fetch（undici），不带 cookie jar
async function authenticateWebHost(url) {
    const response = await fetch(url, { redirect: "manual" });
    if (response.status !== 303 || cookie === null) throw ...
}

// 2) 紧接着 use Electron net.fetch（Chromium），带 cookie jar
async function connectDesktopWelcome(authenticatedUrl, send) {
    const authenticated = await send(authenticatedUrl, { credentials: "include" });
    if (!authenticated.ok) throw new Error("desktop welcome: Web authentication failed");
}

• 第 1 步不带 cookie → 请求头干净 → 拿到 303 ✅
• 第 2 步带上全部 71 个 cookie → 请求头 15.8 KB + 其它头 → 越过 Node 默认 maxHeaderSize（16 KB）→ 服务端返回 4xx → !ok → 启动失败 ❌

所以第一步永远成功、第二步永远失败，稳定复现，不是竞态。

| 0.2.1-rc.4 + 下述补丁 | 同一份 52 KB | ✅ 正常启动 |

建议修复（任选其一）

1. cookie 用固定名字（例如 dsh-auth，不追加随机后缀）——每次启动覆盖上一条，永远只有 1 个；
2. 启动清理：authenticateWebHost 前删掉所有 dsh-auth-*；
3. 或让 connectDesktopWelcome 复用第 1 步拿到的 cookie 头，不走 cookie jar。

临时绕过

完全退出 DSH → 删除下面这个文件 → 重启：

%APPDATA%\@deepseek-ai\dsh-desktop\Cookies

每次清理可再用约 70 次启动。

经过检查rc3版本可稳定复现该bug。

影响面

这是一个累积型定时炸弹：所有长期使用 Desktop 的用户，在约 70 次启动后必然全部启动失败，且报错信息（"Web authentication failed"）完全指向错误方向（认证），会误导排查。

环境

• 平台：Windows 11 x64
• 版本：@deepseek-ai/dsh-desktop 0.2.1-rc.3（Electron 44.7.0 / Node 24.21.0）
• 安装路径：D:\deep seek harness\

严重性：阻断启动 —— 用户无法进入主界面，必须手动删文件才能恢复

影响范围：所有长期使用 Desktop 的用户，约 70 次启动后必现

建议标签：bug desktop blocker startup

修复方案已实测，见本帖回复。

[beyondgjc]

独立复现与代码级补充

另一台环境（Windows 11 x64 / rc.3 / Electron 44.7.0 / Node 24.21.0）今天在同一问题上做了独立排查，结论与主帖完全互相印证，补充三个细节：

1. 第二份独立复现

• cookie 库实测位置是 %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies（SQLite，cookies 表 71 条 dsh-auth-*，全部挂在 127.0.0.1 域下）。
• 每条对应一次历史启动：cookie 名 = dsh-auth- + base64url(sha256(Host authority))，authority 含随机端口 → 每次启动产生新名字，旧的在 Max-Age 30 天内永不覆盖。
• 处置同主帖（关闭桌面端 → 清空 cookies 表 → 重启恢复）。一个佐证细节：清罐前最后一条 mint 记录的时间戳显示，失败那次启动的认证流程已经走到了 303（Set-Cookie 已发出）——失败发生在 mint 之后的环节，与主帖"第二步带上全部 cookie 后失败"一致。

2. 服务端行为的代码级确认（v0.2.1-rc.3 源码 packages/client/connection/src/browser-auth.ts）

authenticate() 按 cookieValue(rawCookie, cookieName(authority)) 只查找当前端口哈希名的那一条 cookie——71 条旧 cookie 对服务端校验完全无感。这把失败原因进一步钉死在主帖的请求头体积路径：不是"旧 cookie 被判无效"，而是 71 条 cookie 把 Cookie 头顶过 maxHeaderSize 后服务端直接 4xx。

3. 支持修复建议三（复用第 1 步的 cookie）

读了 host 侧序列，authenticateWebHost（Node fetch / undici，无 cookie jar）拿到 303 的 set-cookie 后只存进了 hostCookie 变量，从未写回 defaultSession——所以 connectDesktopWelcome 的 cookies() 回调（从 session.defaultSession.cookies.get 读取）只能拿到历史遗留 cookie。让 welcome 连接复用第 1 步显式拿到的 cookie 头，可以完全绕开 jar 一致性问题，改动面也最小。

4. 一个佐证先例（启动清理方案可行）

同一认证 cookie 机制在另一个独立 Electron 载体进程（同样以随机端口 attach runtime 的社区宠物插件 [dsh-agentic-pet]）发生过同款事故：431 条 cookie 撑爆 16 KB 请求头后所有页面请求被拒。载体侧的修复是启动时 session.clearStorageData({ storages: ["cookies"] })——每轮 boot 的 token URL 会重新 mint 所需 cookie，这些 cookie 的持久化本无价值——已稳定运行数周。

附一个小建议：Web authentication failed 在这个场景下有误导性（token/服务本身是好的，坏的是请求头）。connectDesktopWelcome throw 时带上响应状态码（HTTP ${authenticated.status}）的话，下次排查可以直接看到 431/400，省掉"以为 token 坏了"的弯路。

[xiaocangdemiao]

已验证修复

按上述根因在本地打了个补丁，同一份 71 条 cookie 的故障环境，打补丁后可以正常启动。

补丁

位置：apps/desktop/src/main.ts，authenticateWebHost(ready.url) 之前。

        const ready = await host.start()
+
+       // 清掉历史认证 cookie，防止无限制累积
+       for (const stale of await session.defaultSession.cookies.get({ url: ready.url })) {
+         if (stale.name.startsWith('dsh-auth-')) {
+           await session.defaultSession.cookies.remove(ready.url, stale.name)
+         }
+       }
+
        hostCookie = await authenticateWebHost(ready.url)

session 在同文件已导入（458/685/715 行均有使用），无需新增 import。

验证方法

环境	cookie 数	结果
rc.2，正常安装	71 条（52 KB）	❌ Web authentication failed
rc.3，隔离 DSH_HOME（零插件）+ --user-data-dir	同一份 52 KB	❌ 同样失败
rc.4 + 上述补丁，隔离 DSH_HOME + --user-data-dir	同一份 52 KB	✅ 正常进入登录页

关键对照：第 2 行和第 3 行是同一台机器、同一份 cookie 文件，
只差一个补丁——一个起不来，一个正常。

排除项：插件（测试环境 DSH_HOME 为空，未加载任何插件仍复现）、
安装路径（换目录重装仍复现）、版本（rc.2 / rc.3 / rc.4 认证源码一致，
web-document.ts 与 main.ts 在认证路径上 rc.2→0.2.2-alpha.2 哈希完全相同）。

建议修复（任选）

1. 本回复中的客户端清理（4 行，风险最低）
2. 服务端改用固定 cookie 名（如 dsh-auth，不加随机后缀）——每次启动覆盖上一条，永远只有 1 个
3. connectDesktopWelcome 复用 authenticateWebHost 已取得的 cookie 头，不走 cookie jar

临时绕过（对现有用户）

完全退出 DSH → 删除 %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies → 重启。
每次清理可再用约 70 次启动。注意：清完再升级，否则升级后第一次启动可能直接起不来。

[xiaocangdemiao]

补充：rc.4 / rc.5 仍未修复，附 rc.5 实测数据

rc.5 发布后（2026-10-30）复核了 dsh-v0.2.1-rc.5 源码，并在一台机器上实际从 rc.3 升级到 rc.5 做了前后对比。

一、源码比对：认证路径四个版本未变

文件	rc.2	rc.3	rc.4	rc.5
apps/desktop/src/web-document.ts	05ab6fd59199	同	同	同
apps/desktop/src/main.ts	e345eda0425f	同	同	同
apps/desktop/src/welcome-backend.ts	83861a2c4cdd	同	同	同
apps/desktop/src/welcome-api.ts	aeda390c9dbd	同	同	同

web-document.ts 里是 authenticateWebHost，main.ts 里是 hostCookie = await authenticateWebHost(ready.url) 与 connectDesktopWelcome 的调用点。

二、rc.5 实际改了什么

dsh-v0.2.1-rc.4...dsh-v0.2.1-rc.5：4 个提交，300 个改动文件中 281 个是 package.json 版本号，去掉后剩 19 个，全部在 packages/client/ui-chat（思考内容的渲染）。apps/desktop 下唯一改动是 apps/desktop/package.json 的版本号。

三、rc.5 实测：累积行为完全一致

在同一台机器上升级 rc.3 → rc.5，对比 %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies：

• 升级前：13 条 dsh-auth-*
• 升级后启动一次：14 条

每次启动新增一条的行为在 rc.5 上没有任何变化。

### 四、升级提醒

从 rc.3 / rc.4 升到 rc.5 时，**建议先清 Cookies 再升**。升级后第一次启动就要走认证流程，如果那时 jar 已接近阈值，容易当场卡在 `Web authentication failed`——而升级过程本身会让用户以为是「新版本坏了」。

```powershell
# 完全退出 DSH 后执行
Remove-Item "$env:APPDATA\@deepseek-ai\dsh-desktop\Network\Cookies" -Force

[Diaoyulao]

macOS 独立复现：0.2.1-rc.5 仍会因历史认证 cookie 累积而启动失败

2026-11-01 在 macOS 上遇到同样问题，补充跨平台复现证据。

环境与现象

• macOS 26.6.2 / Apple Silicon arm64
• @deepseek-ai/dsh-desktop 0.2.1-rc.5，Electron 44.7.0
• 日常使用后的应用重启无法进入主界面，普通重试仍失败。崩溃日志均指向启动阶段：

phase: startup
app: @deepseek-ai/dsh-desktop 0.2.1-rc.5
electron: 44.7.0
Error: desktop welcome: Web authentication failed
    at connectDesktopWelcome (app.asar/lib/main.js:8886:31)
    at async Object.start (app.asar/lib/main.js:12195:22)

本机实测数据

macOS 的 Cookie 数据库位置：

~/Library/Application Support/@deepseek-ai/dsh-desktop/Cookies

退出应用后检查数据库，host_key = 127.0.0.1 且名称以 dsh-auth- 开头的记录共有 71 条。从故障现场的数据库备份重新统计：

项目	实测值
Cookie 数量	71
名称长度合计	3,692 字节
值长度合计	12,283 字节
按 name=value; ... 拼接的 Cookie 头值长度	16,186 字节（约 15.8 KiB）
每条记录的过期时间减创建时间	30 天

以上只披露数量和长度，未包含任何 cookie 值或认证凭据。

恢复验证

1. 完全退出 DSH，备份 Cookie 数据库。
2. 仅删除 host_key = 127.0.0.1 AND name LIKE 'dsh-auth-%' 的历史本机认证记录，保留其他 cookie。
3. 重新启动，应用恢复正常，能够进入工作界面并加载现有插件。

这次恢复没有修改 DSH 程序代码，也没有为恢复操作调整 profile 或模型凭据。此前的插件更新只是触发了一次重启。

代码核对与建议

本机 rc.5 安装包中仍是先通过 authenticateWebHost(ready.url) 获取 hostCookie，再由 connectDesktopWelcome 调用 net.fetch(..., { credentials: "include" })。后者仅在响应非成功时抛出 Web authentication failed，没有报告状态码。

本机数据和清理前后的结果支持本帖所述的请求头体积问题；本次没有直接捕获失败响应的 HTTP 状态码，不把 431 当成本机已实测结果。

建议启动时清理过期/无用的 dsh-auth-*，并保留当前 Host 的认证隔离；同时在错误中包含 HTTP 状态码。希望修复同时覆盖 macOS 和 Windows。