[Bug] Desktop host: dsh-auth-* Cookie name contains random port, causing startup crash (431)

[Edgeter]

Desktop Host：dsh-auth-* Cookie 名包含随机端口导致无限累积，约 70 次启动后 Cookie: 头超 16 KB，Host 返回 431，应用以 “desktop welcome: Web authentication failed” 启动崩溃

项	内容
产品	DeepSeek Harness（Desktop 端）
版本	@deepseek-ai/dsh-desktop 0.2.1-rc.3（涉及 dsh-client-connection、dsh-host-webserver，同版本）
运行环境	Windows x64 / Electron 44.7.0 / Node 24.21.0（内嵌）
严重程度	High — 应用无法启动且无法自愈；重装、清凭据、禁用插件均无效
影响面	任何在 30 天窗口内启动/重启约 70 次的用户必现（跨平台，非 Windows 特有）
报告日期	2026-10-25
相关仓库	deepseek-ai/deepseek-harness（packages/bundle/base、client-connection、host-webserver、desktop shell）

---

1. 现象（Symptoms）

Windows x64 上启动 Desktop 端，弹窗崩溃，仅显示：

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)
    at async file:///.../app.asar/lib/main.js:7162:5
    at async file:///.../app.asar/lib/main.js:12313:4

崩溃日志位于 %APPDATA%\@deepseek-ai\dsh-desktop\logs\crash-*-host.log，其中：

• source: host、phase: startup；
• (no error-level renderer console output was captured)；
• 无任何 HTTP 状态码、无失败请求、无 Cookie 相关信息。

误导性后果：用户与支持人员会去重装应用、删除 ~/.dsh/.credentials.yaml、点击弹窗自带的 “Restart” 与 “Disable third-party plugins”——全部无效。因为故障点不在这些位置：崩溃发生时 Host 进程已成功启动并 ready，插件也已全部加载完毕。

实测中该现象会自加速：一旦跨过阈值，日志出现每 5 秒一条崩溃记录（恢复窗口的 Restart 循环），且永远不会自行恢复。

---

2. 触发原理（Root Cause，精确到代码行）

2.1 正常握手流程

步骤 1 — Host 侧 WebServer 绑定端口（@deepseek-ai/dsh-web-app/cordis.patch.yml:179）：

- id: webserver
  name: '@deepseek-ai/dsh-host-webserver'
  config:
    host: !!js ctx.webStartup.host ?? '127.0.0.1'
    port: !!js ctx.webStartup.port ?? 3080

Desktop 下 webStartup.port = 0 → 每次启动由 OS 分配随机端口（实测 57738 / 54788 / 55984 / 61311 …）。

步骤 2 — Host 通过 IPC 把 launch URL 发给壳：
ctx.connection.authenticatedUrl('http://127.0.0.1:<随机端口>')，即 /?token=<launchToken>。

步骤 3 — 壳先用 Node 全局 fetch（undici，不带任何 Cookie）换 Cookie：
authenticateWebHost() → 期望 303 + set-cookie。这一步永远成功（因此错误信息不会出现在这里）。

步骤 4 — 壳再用 Electron net.fetch（带 Chromium Cookie 罐）访问同一 launch URL：
connectDesktopWelcome() → GET /?token=… 得 303 → 跟随 Location: ./ → GET /，此时必须携带第 3 步签发的 Cookie。

2.2 缺陷一：Cookie 名包含易变端口（真正的缺陷）

@deepseek-ai/dsh-client-connection/lib/index.js：

// :307  requestAudience —— HTTP 分支保留了端口
function requestAudience(headers, secure) {
    const host = header(headers, "host");     // "127.0.0.1:57738"
    if (host === void 0) return void 0;
    try {
        const url = new URL(`${secure ? "https:" : "http:"}//${host}`);
        return secure ? url.origin : url.host;  // ← 含端口
    } catch { return; }
}

// :335  Cookie 名 = 前缀 + sha256(authority)
function cookieName(authority) {
    return COOKIE_PREFIX + encodeBase64Url(createHash("sha256").update(authority).digest());
}

// :347  固定属性：Path=/、长生命周期、HttpOnly、SameSite=Strict
function sessionCookie(name, value, expiresAt, maxAgeSeconds, secure) {
    const attributes = `${name}=${value}; Max-Age=${String(maxAgeSeconds)}; Path=/; ` +
        `Expires=${new Date(expiresAt).toUTCString()}; HttpOnly; SameSite=Strict`;
    return secure ? `${attributes}; Secure` : attributes;
}

相关常量与默认值：

const COOKIE_PREFIX   = "dsh-auth-";                  // index.js:277
const TOKEN_QUERY     = "token";                      // index.js:276
cookieMaxAgeDays: z.natural().min(1).default(30)      // index.js:1017  （30 天）

因为端口每次随机 → Cookie 名每次不同 → 新 Cookie 无法覆盖旧 Cookie，只能不断累积。

附带的第二个设计矛盾：付了 Max-Age=30d 的“持久浏览器会话 Cookie”，因名字含端口而永远不可能被复用，每次启动必然重新签发——持久化形同虚设。

2.3 缺陷二：Chromium 不按端口隔离 Cookie，Node 默认头部上限 16 KB

• Chromium 对同一 host 的 Cookie 不按端口隔离：GET 127.0.0.1:<新端口>/ 会把 Cookie 罐中所有 127.0.0.1 的 Cookie 全部塞进 Cookie: 请求头。
• Host 是 Node http 服务，默认 maxHeaderSize = 16 KB，超限直接返回 431 Request Header Fields Too Large。
• 壳只判断 if (!response.ok) throw new Error("desktop welcome: Web authentication failed")（app.asar/lib/main.js:8886），把 431 吞成了“认证失败”，既不重试、也不自愈、也不暴露状态码。

于是：没有网络错误、没有认证错误、没有任何日志线索，只有一枚误导性的“认证失败”。

2.4 自加速特性（关键）

每次失败的重试仍然会签发一枚新 Cookie（303 在跟随重定向之前就已返回）。因此一旦跨过阈值，重启越多、情况越糟，永远无法自行恢复。

---

3. 触发条件（量化）

条件	数值
Cookie 名	dsh-auth-<sha256("127.0.0.1:端口")>（base64url，52 字符）
单枚占用	名称 52 B + 值约 120 B ≈ 227 B
Cookie 生命周期	Max-Age = 30 天（cookieMaxAgeDays 默认 30）
Node 默认头部上限	maxHeaderSize = 16,384 B
其他请求头余量	约 250–300 B
阈值	约 71 枚 ≈ 16,117 B → 第 72 次启动起必崩

结论：任何在 30 天窗口内启动/重启约 70 次的用户都会命中。 这与实测数据完全一致（触发时 Cookie 罐内正好 71 枚、16,117 B）。

补充：

• 与操作系统无关（纯 Node 逻辑），macOS / Linux 同样会命中；
• 与代理无关（本地回环被 ProxyOverride 正常绕过，且 Node 侧 fetch 全程成功）；
• 与第三方插件无关（Host 已 ready，插件的加载不参与该失败路径）。

---

4. 实测复现与证据（Reproduction & Evidence）

在用户的真实安装上，使用同一 Electron 44.7.0 二进制（以 resources/default_app.asar 装载自定义主进程），由桌面端同一入口拉起 Host，执行与 Object.start 完全相同的调用序列：

步骤	请求	Cookie 罐状态	结果
1	authenticateWebHost（undici，无 Cookie）GET /?token=…	任意	303 + Set-Cookie ✔
2	net.fetch(launchUrl, {credentials:'include'})	干净（0 枚）	200 ✔
3	同上	用户真实罐（71 枚 / 16,117 B）	431 ✘ → !ok → 崩溃
4	同上，清理 Cookie 罐后	0 枚	200 ✔
5	直连 GET /（无 Cookie）	—	401（设计如此）

关键复现数据：

dsh-auth cookies: 71
approx Cookie header bytes: 16117 (15.7 KB); Node default maxHeaderSize = 16 KB
other cookies: 0

清理后重新执行同一序列：

1) net.fetch(launchUrl, {credentials:include}) [follow] -> 200
2) cookie jar entries for url: dsh-auth-… httpOnly=true sameSite=strict
5) net.fetch(origin + /) -> 200

启动真实应用：5 个进程存活、主窗口正常出现、未产生新的崩溃日志。

4.1 给官方的最小复现脚本要点

无需用户环境即可复现：

• 在测试机上先用 session.cookies.set() 预置 71 枚 dsh-auth-*（Path=/、HttpOnly、SameSite=Strict），再执行 net.fetch(launchUrl, {credentials:'include'})；
• 或直接循环启动 Host 71 次（每次随机端口 → 天然累积），第 72 次启动即稳定复现 431 与上述异常。

---

5. 建议修复方案（Fix Proposal）

方案 A（推荐，最小切口，并顺带修掉“持久 Cookie 永不生效”）

让 authority 不含易变端口，使同一次安装/同一 host 下 Cookie 名稳定 → 每次启动覆盖而非新增：

// requestAudience：HTTP 也用 hostname（或 origin 但去掉端口）
function requestAudience(headers, secure) {
    const host = header(headers, "host");
    if (host === void 0) return void 0;
    try {
        const url = new URL(`${secure ? "https:" : "http:"}//${host}`);
        return `${url.protocol}//${url.hostname}`;   // 例：http://127.0.0.1
    } catch { return; }
}

安全性不再依赖端口：真正的凭证是签名密钥（client-connection/browser-session 记录）+ launchToken，端口不构成安全边界；isAuthenticated / authenticate 只需与签发侧使用同一 requestAudience，两侧一致即可。

附带收益：Cookie 名稳定后，Max-Age = 30 天 的持久会话才真正可用。

方案 B（兜底，防历史脏数据）

启动时清理不匹配当前 authority 的历史 Cookie（壳侧）：

const jar = await session.defaultSession.cookies.get({ url: ready.url });
for (const c of jar) {
    if (c.name.startsWith('dsh-auth-') && c.name !== currentName) {
        await session.defaultSession.cookies.remove(ready.url, c.name);
    }
}

方案 C（必须做：可诊断性 / 自愈）

C1 — 壳侧错误信息带上状态码：

if (!authenticated.ok)
    throw new Error(
        `desktop welcome: Web authentication failed (HTTP ${authenticated.status} ${authenticated.statusText})`
    );

C2 — 识别 431 时给出明确指引（“浏览器 Cookie 数据超限或损坏，请清理 Cookie 后重启”），并自动清理一次 Cookie 后重试（自愈）。

C3 — Host 侧可考虑 createServer({ maxHeaderSize: 64 * 1024 }) 作为纵深防御，但不应替代方案 A。

---

6. 用户侧临时规避（Workaround）

必须完全退出应用（Network\Cookies 被独占锁住），然后二选一：

① 外科式（推荐：仅删 dsh-auth-*，保留其他站点/平台登录 Cookie）

对 SQLite 库 %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies 执行：

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

② 粗暴式

Remove-Item "$env:APPDATA\@deepseek-ai\dsh-desktop\Network\Cookies" -Force

重要陷阱：删除 ~/.dsh/.credentials.yaml 中的 client-connection/browser-session 记录只会更换签名密钥。那 71 枚旧 Cookie 仍然留在罐中、照旧占用头部体积，请求头大小完全不变，故障必然复现。建议在支持文档中显式排除该做法。

复发周期：清空后约再启动 70 次复现（按 dsh-auth-* 均值 227 B 估算）。

---

7. 期望行为（Expected Behavior）

1. Cookie 名不包含每次变化的端口，长期使用不会累积；
2. 即使 Cookie 罐异常，启动失败也应暴露真实原因（HTTP 状态码）而非“认证失败”；
3. 对 431 这类可自愈故障，壳应自动清理并重试一次，而不是把整个应用卡死在启动阶段。

---

8. 附：验证环境与方法说明

• 通过 Windows 硬链接构造同版本 Electron 的“壳”（resources/default_app.asar + 自定义 app 目录），以完全相同的二进制执行 net.fetch / session.cookies 调用，避免依赖推测；
• Host 由桌面端同一入口 @deepseek-ai/dsh-desktop-host/lib/index.js 以 ELECTRON_RUN_AS_NODE=1 拉起，参数与环境变量与生产一致；
• 源码定位通过解析 app.asar 头部读取 lib/main.js、dsh/node_modules/@deepseek-ai/* 原始文件完成（行号为 0.2.1-rc.3 包内实际行号）。

[Edgeter]

关联：本条与 #10809 是同一问题（同一处 main.js:8886、同样 71 枚 dsh-auth-* 累积）。

两点交叉验证/更正：

1. 超限时服务端实测返回的是 431 Request Header Fields Too Large（Node http 默认 maxHeaderSize 16 KB），
   而非 401；401 只在 Cookie 缺失或签名失效时出现。这一点会影响修复判断。
2. 根因可定位到 @deepseek-ai/dsh-client-connection/lib/index.js:307 requestAudience()
   在 HTTP 分支保留了随机端口，导致 cookieName()（:335）每次启动都不同、旧 Cookie 无法被覆盖。

@Gniy7Ga 麻烦帮忙 triage 一下这条 bug 报告（与 #10809 同因，这里补了行号级根因和 431 的更正）：

• 本条目前在 Q&A，能否移到 General（本仓库 bug 帖的惯例落点）？
• 需要最小复现脚本（Node / Electron 各一版）的话我马上补，可直接贴在本帖。

补充说明：我这边已通过清理 Cookie 自行恢复，发帖是为了让根因进入修复流程，不是求助；本贴不是提问，请勿标记为答案。