[Bug] 桌面版「Web authentication failed」：Host 已回 303，跟随重定向时历史 dsh-auth cookie 触发 431（0.2.1-rc.2）

[Ozx-68102]

桌面版启动被「Web authentication failed」挡住，Host 的 303 是成功的，失败的是 431

某一次关掉DeepSeek Harness之后直接报错，无论怎么点击「禁用第三方插件、备份profile patch并重启」都起不来。然后我用Cursor（Grok 4.7）修好的，我想把这个经历分享出来。下面是Cursor的报告。

报错图

环境

项	值
产品	DeepSeek Harness 桌面版
版本	0.2.1-rc.2（Electron 44.7.0 / Node 24.21.0）
系统	macOS，darwin arm64
崩溃阶段	source: host，phase: startup
cookie 库	~/Library/Application Support/@deepseek-ai/dsh-desktop/Cookies
复现	冷启动次数积到约 70 次后必现；删掉下述 cookie 后当次恢复

复现

1. 冷启动桌面版两次。两次的 Host 都是 --port 0。
2. 打开上面的 Cookies。host_key = 127.0.0.1 且 name LIKE 'dsh-auth-%' 的行增加两条，名字不同。
3. 重复冷启动，直到这种行累积到约 70 条，再启动。对话框即为上面的错误。
4. 完全退出，备份 Cookies，执行文末 SQL，再启动。应用打开，库里重新只有 1 条 dsh-auth-*。

不必真的启动 70 次才能确认头上限。Host 起来之后，对它打印的 http://127.0.0.1:<port>/?token=... 发带 token 的 GET，Cookie 头用等长的填充：

Cookie 头长度	同时带上 Electron 量级的 User-Agent / Accept-Language / Accept-Encoding	状态
15730（约 69 条真实 cookie）	是	303
15958（约 70 条）	是	303
16050 及以上（约 71 条是 16186）	是	431

303 上的 Set-Cookie 单独拿去请求去掉 token 的 /，状态是 200 text/html。PRAGMA integrity_check 在 71 条时为 ok。

根因

抛错在安装包 DeepSeek Harness.app/Contents/Resources/app.asar/lib/main.js 第 8886 行，函数 connectDesktopWelcome（打包注释标的源文件是 lib/types/welcome-backend.js）。状态码没有进入消息：

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

send 是 Electron net.fetch，默认跟随重定向。前面一步是同文件约 8229–8233 行的 authenticateWebHost（打包注释 lib/types/web-document.js）。它用 Node fetch，redirect: "manual"，而且不读 Electron 的 cookie 罐：

const response = await fetch(url, { redirect: "manual" });
const cookie = response.headers.get("set-cookie");
if (response.status !== 303 || cookie === null)
  throw new Error("Desktop Host authentication failed");

这次崩溃日志是前一句，不是后一句，所以 Host 已经返回了 303 和 Set-Cookie。

cookie 名字把当次端口算了进去。代码在安装包 app.asar 内的 dsh/node_modules/@deepseek-ai/dsh-client-connection/lib/index.js，打包注释标的源文件是 lib/types/browser-auth.js：

function requestAudience(headers, secure) {
  const host = header(headers, "host");
  const url = new URL(`${secure ? "https:" : "http:"}//${host}`);
  return secure ? url.origin : url.host; // HTTP 下是 127.0.0.1:<port>
}
function cookieName(authority) {
  return "dsh-auth-" + base64url(sha256(authority));
}

sessionCookie 写的是 Path=/; HttpOnly; SameSite=Strict，Max-Age 为 30 天。浏览器按 host 发送，不按端口过滤。--port 0 使每次启动的名字都不同，新的 Set-Cookie 不会覆盖旧行。70 条左右之后，net.fetch 跟随 Location: ./ 时带上全部历史 cookie，请求头超过 Node 默认的 16384，Host 回 431，response.ok === false，界面仍显示认证失败。

本机 71 条的时间跨度大约 6 天。失败那一次库里的条数加了 1（303 的 Set-Cookie 已入库），再启动就不再增加，和「第一跳本身已经 431」一致。

崩溃对话框为什么清不掉

「禁用第三方插件、备份 profile patch 并重启」调用 sanitizeProfile：把 cordis.patch.yml rename 成 cordis.patch.yml.bak-<毫秒>，再把 dsh.profile.bundles 写成 ["@deepseek-ai/dsh-base", "@deepseek-ai/dsh-web-app"]。下次启动发现 patch 不在，写入空数组 []。

cookie 库不在这个函数里。插件卸掉之后，431 还在。cordis.patch.yml 里同时放着模型、locale、默认模型；这一步会把这些设置一起换成 []。profile 目录里会留下 .bak-<毫秒>，可以从那里拼回去。

建议修复

1. loopback 的 cookie 名不要哈希端口。requestAudience 在 HTTP loopback 上返回 hostname（或固定字符串），让下一次 Set-Cookie 覆盖同一行。调大 max-http-header-size 只是把阈值往后推。
2. 上面的 throw 带上状态码：`desktop welcome: Web authentication failed (HTTP ${authenticated.status})`。431 和 401 现在是同一句。
3. sanitizeProfile 继续重置 bundles 即可。用户 patch 已有 .bak，不要在同一次恢复里把生效文件换成 []。若要针对这次对话框提供恢复，退出后删除 host_key='127.0.0.1' AND name LIKE 'dsh-auth-%'，保留当次进程新写的那一条。

当前变通

完全退出后备份 Cookies，执行：

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

不要改 Partitions/ 下的 cookie 库。重新打开后应只新增 1 条 dsh-auth-*。这些行对应已经退出的随机端口。命名不改的话，冷启动频繁的机器过几十天会再满，同一条语句仍然适用。

[qingyoujiu79]

Windows x64 同样复现。两处补充：
1）Windows 的库在 %APPDATA%@deepseek-ai\dsh-desktop\Network\Cookies（多一层 Network\），按帖里的 macOS 路径找不到；
2）干净 GET /（去 token）实测：70 条 = 15958 B → 401，71 条 = 16186 B → 431，说明只差 228 字节且与 cookie 有效性无关。另外卸载重装不清这个库。
环境：0.2.1-rc.2 / Electron 44.7.0 / Node 24.21.0，堆栈与主帖一致。