crash, maybe a bug

[zuosus]

quoted from opencode that helped restore DeepSeek Harness from crashing:

结论
这不是你的插件补丁导致的。 我把 vsceditor-desktop-control-fence.mjs 还原成官方围栏后重新启动，仍然出现完全相同的 desktop welcome: Web authentication failed。这个补丁只改插件里的写操作围栏，而且它生效的时候 Host 早就已经启动完了，和启动失败无关。
真正的原因
桌面端每次启动都会生成一张新的本地认证 cookie：

• 名字形如 dsh-auth-<随机串>
• 域名 127.0.0.1
• 有效期 30 天
• 旧 cookie 从来不删除
  崩溃时，Cookie 库里已经堆了 71 张这样的 cookie。
  启动过程中，connectDesktopWelcome() 会执行：
  net.fetch(..., { credentials: "include" })
  浏览器会把 127.0.0.1 下所有 cookie 全部塞进 Cookie 请求头。第一次请求拿到 303 后，服务端又发一张新 cookie，于是重定向请求带上了 71 张旧 cookie + 1 张新 cookie = 72 张。
  这个 Cookie 头大约 16.4 KB，超过 Node 默认的 16 KiB HTTP 头限制，Host 直接返回：
  431 Request Header Fields Too Large
  而桌面壳只判断了 !response.ok，所以日志里显示成误导性的：
  desktop welcome: Web authentication failed
  我直接对 Host 做了验证：
• 71 张 cookie → 303
• 72 张 cookie → 431
  和上面的分析完全一致。
  已经做的修复
  清理了：
  ~/Library/Application Support/@deepseek-ai/dsh-desktop/Cookies
  里面积累的旧 dsh-auth-* cookie。清理前脚本会先备份整个 cookie 库。
  当前状态：
• dsh-auth cookie：1 张，约 228 字节
• DSH 已在 00:11 正常启动
• 之后没有再产生新的启动崩溃日志
• vsceditor 的控制面围栏补丁仍然在位
  注意：围栏补丁要继续保留。它修的是另一个问题——桌面面板里切换跟随、改配置、装扩展等写操作报 403；和这次的启动失败是两回事。
  以后怎么避免
  这个泄漏会随着每次启动慢慢回来，每启动一次多一张 cookie。可以定期检查：
  sh ~/.dsh/patches/dsh-desktop-cookie-prune.sh --check
  当数量比较多（比如 50 张以上）时，先退出 DSH，再执行：
  sh ~/.dsh/patches/dsh-desktop-cookie-prune.sh
  删除是安全的：每次启动都会重新签发 launch token，旧 cookie 对下一次启动没有任何用处。
  如果需要，我也可以再加一个 LaunchAgent，在 DSH 没运行时自动清理，这样就不用手动记着跑脚本了。
  Build · DeepSeek V4.1 Flash Free · 10.8s · 72.1 tok/s
  这个问题和插件无关？是 dsh 自己的问题？
  +Thought · 9.6s
  是的，和 dsh-vsceditor 插件无关，这是 DSH 桌面端自身的问题。
  更准确地说，是 DSH 桌面端认证 cookie 管理上的一个上游缺陷，加上错误提示写得过于笼统，导致看起来像“认证失败”。
  为什么说和插件无关
  我做过对照实验：

1. 把 vsceditor-desktop-control-fence.mjs 还原成官方围栏；
2. 重新启动 DSH；
3. 仍然出现一模一样的：
   desktop welcome: Web authentication failed
   所以补丁不是原因。它改的是插件里“写操作是否放行”的逻辑，而崩溃发生在 DSH 桌面壳连接 Host 的阶段，那时插件还没参与请求处理。
   为什么看起来像是插件引起的
   时间上确实是巧合：

• 你改完插件后需要重启 DSH；
• 而当时 cookie 库里已经积累到 71 张 dsh-auth-* cookie；
• 这次重启又生成第 72 张，重定向请求的 Cookie 头超过 16 KiB；
• Host 返回 431，桌面壳报“Web authentication failed”。
  也就是说，插件补丁只是触发了那次重启；即使你不改插件，下一次重启同样会失败，只是时间早晚问题。
  DSH 自身的问题出在哪
  核心是两点：

1. cookie 只增不减

• 桌面端每次启动都会生成一张新的 dsh-auth-<随机串>；
• cookie 名和本次启动的 127.0.0.1:<随机端口> 绑定；
• 有效期 30 天，旧 cookie 从不清理；
• 每次启动都会多一张，最终把请求头撑爆。

2. 错误提示掩盖了真实原因

• Host 实际返回的是 431 Request Header Fields Too Large；
• 桌面壳只判断 !response.ok，统一报成“Web authentication failed”；
• 于是错误信息把人引向“认证”和“插件”，而不是 cookie 头过大。
  所以这是 DSH 桌面端的上游 bug，不是你的插件改坏了，也不是 trustedHosts 配错。
  结论
• vsceditor-desktop-control-fence.mjs：保留，它修的是另一个真实问题——桌面面板写操作 403。
• 启动失败：DSH 自身的 cookie 泄漏问题，已经通过清理旧 dsh-auth-* cookie 解决。
• 以后如果再次出现同样的启动失败，先跑：
  sh ~/.dsh/patches/dsh-desktop-cookie-prune.sh --check
  数量多了就退出 DSH 后清理：
  sh ~/.dsh/patches/dsh-desktop-cookie-prune.sh
  这本质上是在等上游修复前的临时规避方案。