前言¶
DSH（DeepSeek Harness）桌面版每次启动都会在本地随机端口上拉起宿主进程，并通过浏览器会话完成 Web 认证。这条路径在反复启动后会碰到一个与「登录失效」无关的故障：Chromium 里 dsh-auth-* Cookie 越积越多，最终把 Cookie 请求头撑到 Node 默认上限附近，HTTP 层直接返回 431，壳层则统一报成 Web authentication failed。
手工删除整份 Cookies 数据库只能临时止血，且会连带清掉其他站点状态。下面介绍社区插件 dsh-auth-cookie-guard（维护者 vi0let-dev，分类：客户端）：它在每次页面加载后自动只删多余的 dsh-auth-*，保留当前端口那一枚，并在设置页给出数量与风险指标。
这是什么¶
dsh-auth-cookie-guard 是 DSH 桌面版插件，针对报错形态大致如下：
Error: desktop welcome: Web authentication failed
at connectDesktopWelcome (.../lib/main.js:...)
根因是认证 Cookie 命名带端口哈希，而 Chromium 按主机隔离 Cookie、不按端口；127.0.0.1 上历次启动留下的 dsh-auth-* 会随请求一并发送。每启动一次多一枚，默认约 30 天过期；按 README 估算，大约 70～90 次启动后请求头可能逼近 16 KiB 上限。
插件不把「清 Cookie」留给用户手工删库，而是在运行中通过同源 API 与 Set-Cookie 让浏览器只保留当前宿主端口对应的一枚，其余过期删除。它不读会话内容、不写用户目录、不联网，也不删除非 dsh-auth-* 的 Cookie。
问题机制（简要）¶
理解插件行为，需要先弄清桌面版的几条事实（均来自项目 README）：
- 桌面版启动时宿主绑定新的回环端口（实测落在
1024–15000段，例如127.0.0.1:13708）。 - 会话 Cookie 名为
dsh-auth-<base64url(sha256("host:port"))>，名字里编码了端口。 - 同一主机下所有
dsh-auth-*会在每次请求里一起发出；累积到数十枚后，Cookie头过长触发 431，应用代码来不及介入。
因此适合用插件做「每次启动后的定向清理」，而不是反复删整库。
核心功能¶
README 中列出的能力如下，安装后一般无需额外操作即可生效。
| 能力 | 说明 |
|---|---|
| 启动自动清理 | 页面加载后向插件路由发同源请求；从 Cookie 头读出所有 dsh-auth-*，只保留当前端口那一枚，其余用 Set-Cookie 置空删除 |
| 设置页状态 | 设置 →「认证 Cookie 守卫」：当前宿主地址、当前 Cookie 短名、上次请求携带数量与估算字节、风险分级、上次清理结果 |
| 一键清理 | 「立即清理」立即执行一次并回显删除数量 |
| 页面内配置 | enabled、dryRun、warnAt 可在设置页切换并保存，写入当前 profile 的 cordis.patch.yml |
| 救援脚本 | 已 431 无法打开桌面版时，退出应用后运行 scripts/purge-auth-cookies.mjs，备份后只删 dsh-auth-* 相关行 |
安全边界（README 强调）：路由要求 loopback 的 Host 与同源自定义头 x-dsh-auth-cookie-guard；当前端口 Cookie 缺失时整批放弃删除，避免误踢会话；单次响应最多删除 180 枚。运行时零第三方依赖，救援脚本使用 Node 内置 node:sqlite（要求 Node ^22.19.0 || >=24.0.0）。
安装与启用¶
安装后需重启 DSH 才会加载新的 JS 模块。官方 README 给出两种方式（二选一，本仓库不代你执行）：
dsh plugin --profile desktop add github:vi0let-dev/dsh-auth-cookie-guard
本地开发或从目录安装时：
dsh plugin --profile desktop add <本目录绝对路径>
也可在 DSH 插件管理页添加。package.json 标明插件版本 0.2.2，DSH 引擎要求 >=0.2.1-rc.2 <0.3.0。
安装前应自行查看 GitHub 仓库 源码与 MIT 许可证；插件在 DSH 进程权限下运行，与任意社区插件一样，信任边界由你决定。
典型用法¶
经过上面的步骤重启桌面版之后，可按三种粒度使用。
1. 自动模式（默认）
enabled 默认为 true，每次启动自动清理旧的认证 Cookie，通常无需手动干预。
2. 手动清理与状态
打开 设置 →「认证 Cookie 守卫」→「立即清理」。页面上「上次请求携带 N 枚认证 Cookie」中的 N 是是否接近风险的关键指标；README 建议健康值长期维持在 1～2。
3. 已经打不开桌面版时
页面加载是自动清理的前提；请求头已超限、启动直接失败时，需在完全退出桌面版后运行救援脚本：
# 1. 完全退出桌面版（托盘退出，并确认无残留进程）
# 2. 在插件目录下运行：
node scripts/purge-auth-cookies.mjs
# 只想先看看有多少枚、不改数据：
node scripts/purge-auth-cookies.mjs --dry-run
脚本会备份 Cookies 数据库（同目录生成 Cookies.dsh-cookie-guard-<时间戳>.bak），再只处理 127.0.0.1 / localhost 上名为 dsh-auth-* 的条目。Windows 上数据库路径为 %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies；macOS/Linux 由脚本按平台推导。
配置项¶
三个开关可在设置页修改，点「保存」经 DSH configEditor 写入当前 profile 的 cordis.patch.yml（非插件包内默认文件，升级插件不会覆盖你已保存的项）。
| 字段 | 类型 | 默认 | 说明 |
|---|---|---|---|
enabled |
boolean | true |
启动时自动清理；关闭后仅保留手动「立即清理」 |
dryRun |
boolean | false |
只报告不删除，用于观察将清掉哪些 Cookie |
warnAt |
integer 1–500 | 40 |
设置页开始黄色告警的 Cookie 条数 |
「立即清理」不受 enabled / dryRun 限制。若当前 profile 没有 configEditor，页面会提示无法保存，仍可手改 profile 的 cordis.patch.yml。
适用场景与注意¶
适合谁：长期使用 DSH 桌面版、启动频繁、或曾遇到 Web authentication failed 且怀疑 Cookie 头过长的一线开发者。
已知限制（README）：
- 自动清理只对「能成功加载页面」的启动有效；已 431 的状态必须先跑救援脚本。
- 插件无法直接改 Chromium 的
Cookies数据库（运行中被独占），修复一律走浏览器应答。 - 宿主若改用
https或非127.0.0.1主机名，删除逻辑以getOrigin()为准；跨主机名情形未全覆盖。 - 仓库说明真机 Electron 行为以本地测试与
AUDIT.md为准，安装前可自行核对。
卸载：在插件管理页停用并移除，重启 DSH；可能的残留仅为救援脚本生成的 Cookies.dsh-cookie-guard-*.bak 备份。
结尾¶
dsh-auth-cookie-guard 把桌面版 dsh-auth-* Cookie 累积问题从「偶尔删库」变成「每次启动定向清理 + 可观测阈值」，降低因请求头超限导致的启动失败概率。
DSH 生态主张「一切皆插件」；SkillHub 等目录为社区站点，与 DeepSeek / 幻方无官方从属关系。选用插件时请以自己的环境、许可证与源码审计结论为准。
