DSH Desktop启动报错：desktop welcome: Web authentication failed

[kokeo]

今早上班打开DSH桌面端，总是失败，哪怕禁用插件启动都报错，如图：

用豆包分析并修复成功：

已经找到根因：Chromium 发出的请求带了 16603 字节请求头，Host 返回 HTTP/1.1 431 Request Header Fields Too Large。Cookie 库里累积了 71 条同一域 127.0.0.1 的 dsh-auth-* cookie，每次启动一个新端口就新增一条、永不清理，最终把请求头撑爆。接下来清理这些 cookie。

=====
清理完成就成功打开了。

[CycSpring]

补充一个已经在 Windows 桌面端 0.2.2-rc.1 上验证的临时规避办法：固定 Desktop Host 端口，再定向清理一次遗留认证 Cookie。可以保留现有安装包和历史会话。

本机此前曾触发过一次 431，随后重装了 Harness。本轮检查时仍发现 34 条未过期的 dsh-auth-* Cookie。下面验证的是防止继续堆积的规避方案，未验证其他版本。

为什么固定端口有效

这个版本按包含端口的 Host authority 生成 Cookie 名称，桌面端启动时又传入 --port 0，由系统分配空闲端口。端口改变会生成不同名称的 Cookie；而浏览器 Cookie 不按端口隔离（RFC 6265 §8.5），所以同一 127.0.0.1 下、路径匹配的旧 Cookie 仍会随请求发送。

该版本默认 Cookie 有效期为 30 天，因此频繁重启时会在有效期内不断堆积。固定相同的主机名和端口后，新 Cookie 可以覆盖同名旧值；已有的其他名称 Cookie 则需要清理或等待过期。

1. 在桌面端用户配置中固定端口

先完全退出 Harness，包括托盘中的后台进程。编辑默认位置：

%USERPROFILE%\.dsh\profiles\desktop\cordis.patch.yml

如果设置过 DSH_HOME，则对应为 <DSH_HOME>\profiles\desktop\cordis.patch.yml。先备份此文件。

在现有顶层 YAML 列表末尾添加以下条目。若已有 id: webserver 的覆写，请修改原条目，并保留自己的其余配置。下面是按该版本默认配置填写的示例：

- id: webserver
  name: "@deepseek-ai/dsh-host-webserver"
  config:
    host: "127.0.0.1"
    port: 17863
    tls: !!js ctx.webStartup.tls
    compression: gzip
    compressionLevel: 1
    compressionThresholdBytes: 1024

17863 只是本次验证使用的空闲端口，可换成自己确认未被占用的端口；绑定地址保持 127.0.0.1。固定端口被其他进程占用时，需要释放它或换一个端口。

注意编辑的是 cordis.patch.yml：该版本启动时会重写作为空根的 cordis.yml。用户补丁可以把 webserver 默认的动态端口表达式替换为固定值，即使桌面端内部仍传入 --port 0，本次测试也能生效，无需修改 app.asar。

2. 定向清理已经堆积的本地认证 Cookie

固定端口不会立即清除之前的 Cookie。确认 Harness 已完全退出后，先备份桌面端 Cookie 数据库，默认位置是：

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

用 SQLite 工具打开这一个数据库，先查看目标数量：

SELECT COUNT(*)
FROM cookies
WHERE host_key = '127.0.0.1'
  AND path = '/'
  AND name GLOB 'dsh-auth-*';

确认备份完成后，执行定向删除：

BEGIN TRANSACTION;
DELETE FROM cookies
WHERE host_key = '127.0.0.1'
  AND path = '/'
  AND name GLOB 'dsh-auth-*';
COMMIT;
PRAGMA quick_check;

这只清理桌面端本地 Host 的认证 Cookie，下一次启动会重新生成；不删除 <DSH_HOME>\sessions 中的历史会话文件。Cookie 备份留在本机即可，无需上传。

本次验证结果

• 两次独立启动均监听 127.0.0.1:17863，桌面端正常打开，历史会话列表正常显示。
• 清理了 34 条旧认证 Cookie；第一次启动并完全退出后为 1 条，第二次启动并完全退出后仍为 1 条。
• Cookie 请求头字段值从 7,750 字节降到 226 字节（均不含其他 HTTP 请求头）。
• 原有历史会话文件逐个进行 SHA-256 校验，全部与操作前一致，无缺失、无修改。
• 用户配置经过重启后保留，Cookie 数据库 quick_check 通过。

如需恢复随机端口，完全退出后移除新增的 webserver 配置条目即可，通常不需要恢复旧 Cookie。

这仍属于用户侧规避。程序侧可以考虑在首次携带 Chromium Cookie 请求 Host 之前，清理该桌面端自有会话里遗留的旧 Host 认证 Cookie，或调整其会话存储方式。仅在业务鉴权时忽略旧 Cookie 无法解决请求头超限，因为 431 会先在 HTTP 解析阶段发生。

[modusensus]

补充一台独立 Windows 机器的实测，确认 #12698 与 CycSpring 的根因判断；同时想请维护者注意一处会误导排查方向的报错文案。

先谢过 @kokeo 把崩溃日志原样贴出来，也谢 CycSpring 那条固定端口的方案——我照着在本机验证有效，省掉了我重装。

本机数据（127.0.0.1，Cookie 库 %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies）：

• dsh-auth-* 累积 71 条，host_key 全为 127.0.0.1、path=/，71 个互不相同的 source_port；最早 11-01 08:25，最新 11-09 10:45。
• 每条定长 225 字节（名称 52 + 值 173），合计 Cookie 头 16,115 字节；加上 UA / Sec-Fetch-* 等常规头约 600 字节，越过 Node http 服务器默认 maxHeaderSize=16384。
• 本机用未加配置的 node v24 http 服务单独复现：超大 Cookie 头 → HTTP 431，与 CycSpring 观察一致。
• 时间线可核验：第 70 条写入后那次启动（10:44）仍能进入渲染进程；第 71 条写入后（10:45:49）连续 6 次启动全部失败，崩溃日志字节数完全相同。

想请维护者看的一处文案问题（也是我认为代价最高的部分）：失败发生在 connectDesktopWelcome 用 net.fetch（带 cookie jar）跟随那枚 303 之后，而前一步 authenticateWebHost 用的是 Node 原生 fetch——它没有 cookie jar，请求头很小，所以那一步成功拿到了 303。两条请求唯一的差别就是带不带 cookie，但代码把任何 non-ok 都写成 Error("desktop welcome: Web authentication failed")，于是本地请求头超限被伪装成「账号 / 登录 / 鉴权失败」。按这个报错去查登录态、重装、清 profile 的用户（包括我自己一开始）都会走弯路，而真实修法只有清 Network\Cookies 里的 dsh-auth-* 或固定 Host 端口。

建议任选其一：

1. 在该分支保留 HTTP status，把「431 / 传输层失败」与「鉴权拒绝」分开报，别再统一写成 authentication failed；
2. 宿主在签发新 cookie 时删除同前缀的遗留 dsh-auth-*，或把它改成不带 Expires / Max-Age 的会话 cookie——现在是 30 天持久，且名字派生自临时端口，于是每次启动净增一条。

另外一个会恶化的点：每失败一次重启就再多一条 cookie，所以点「重启」只会更糟，不可能自愈。按本机约每天 7 次启动，从干净库到再次触顶约 10 天——在正式修复前，CycSpring 的固定端口规避是目前唯一能长期站得住的用户侧办法。

供 triage 参考，同根因的帖子（我按标题/正文检索 431 得到的，可能还有遗漏）：#11095 #11239 #11397 #11590 #11624 #11758 #11764 #11968 #12080 #12280 #12360 #12377 #12488 #12585 #12586 #12698。两周 16 帖、0.2.2-rc.1 仍复现，这个重复量本身就是优先级信号。

English TL;DR: independently confirmed on another Windows machine — 71 port-keyed dsh-auth-* cookies (225 B each, a 16,115 B Cookie header) trip Node's 16 KB maxHeaderSize, so the loopback request fails with HTTP 431 before any auth logic runs. The misleading part: the preceding hop (authenticateWebHost, Node fetch, no cookie jar) succeeds, so a local header-size failure is surfaced as "desktop welcome: Web authentication failed". Please keep the HTTP status and distinguish transport failure from an auth rejection, and consider a session cookie or pruning stale dsh-auth-* names. Each failed relaunch adds another cookie, so the app cannot self-heal; roughly 10 days to re-hit the ceiling at my launch rate.

（本机标识 modusensus；以上数字均取自本地文件测量，未上传任何配置或凭据。）