dsh-reclaim
审计 DeepSeek Harness 的磁盘使用情况（会话、附件、可重建缓存），按风险进行分类，并将你选择删除的内容移入插件自身的可恢复回收站。模型可以查询，但绝不删除。
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:gankudadiz/dsh-reclaim#e21b0aa3c741a22568813ed9f4288d3f7771f069Reclaim 以 dsh-reclaim 发布，当前版本为 0.1.0。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
点击下方 Badge 复制 Markdown，粘贴到 README 即可。
验证 package.json 声明的 GitHub 仓库，即可管理这个公开页面。认领后，Hub 会优先安排当前版本的安全扫描，并在通过后公开展示结果。
认领这个 Plugin →Audit and safely reclaim the disk space DeepSeek Harness keeps forever. 审计并安全回收 DeepSeek Harness 永久占用的磁盘空间。
DSH 插件。功能已完成，尚未发布到 npm——安装方式见下方「安装」。
DSH 官方明确不回收附件。@deepseek-ai/dsh-attachment-local 的 README 原文：
Images are kept forever — stored images are never deleted automatically, and nothing collects unreferenced objects.
官方也说明了推迟的原因：
Retention and garbage collection are deferred because resumed and forked sessions may share immutable objects …
也就是说，这不是漏做，而是一个需要先解决正确性问题的功能。dsh-reclaim 把它做出来，并且尊重官方指出的那条约束。
功能已经完成并通过验证，但尚未发布到 npm，所以 dsh plugin add dsh-reclaim 目前还装不到。
在发布之前，可以本地安装：npm pack 生成 tgz → dsh plugin --profile web add file:<tgz>。
发布之后，安装就是一条命令——装进一个带 web 层的 profile（也就是平时用来开界面的那个）：
dsh plugin --profile web add dsh-reclaim
dsh web
装完打开 设置 → 空间回收。
⚠️ 不要装进一个全新的空 profile。
dsh plugin --profile <新名字> add <包>建出来的 profile 只带@deepseek-ai/dsh-base，里面没有任何东西提供 web 连接层，插件会一直停在pending (waiting for service: connection)，宿主启动失败。要用自己的 profile 时，让它包含@deepseek-ai/dsh-web-app（例如以自带的web模板为底），再装本插件。
装好后想确认它在服务，可以直接问它：
curl -b <会话 cookie> http://127.0.0.1:<端口>/api/dsh-reclaim/health
DSH 处于 developer preview，官方 README 明确写着「THERE WILL BE COMPATIBILITY-BREAKING CHANGES」。 而且它不强制检查插件声明的兼容范围（
engines.dsh/dsh.manifestVersion官方原话是"仅作声明"， 安装器与加载器都不校验）。所以：装得上不等于跑得对，声明范围只能当文档读。
| 支持的 DSH | 状态 | 说明 |
|---|---|---|
0.1.5-rc.1 … 0.1.5-rc.3 | 已验证 | DSH 0.1.5-rc.1 宿主 + 0.1.5-rc.2 依赖包，真实数据 + 真实浏览器 |
0.1.7-rc.1 | 已验证 | 独立 home + 0.1.7-rc.1 的完整依赖树（277 个包）。能力探测 7/7 通过；该版本导出 dshCachePath，插件据此自动改选了新布局 cache/attachments/request-images；真实浏览器面板正常 |
0.1.6-* | 推断，未实测 | 位于两个已验证版本之间，故一并纳入范围；真要依赖它之前建议先验一遍 |
版本范围的实现方式值得说明：必须逐 minor 串 OR 子句，
>=0.1.5-rc.1 <0.2.0 || >=0.1.6-0 <0.1.7-0 || >=0.1.7-0 <0.1.8-0。 每条带止于下一个 minor，因此它只声明这三个已验证的 minor——未发布的0.1.8不在其中。engines.dsh与peerDependencies里这段文本逐字相同，避免两者漂移。
装好之后，一条请求就能看出当前宿主对不对得上——/health 的 capabilities 字段逐项列出本插件依赖的
宿主接口在不在（ctx.effect、ctx.connection.fetch.register、ctx.get，以及 sessions / attachments /
sessionQuery / tools 四个服务），每项都写明缺了会坏什么。版本对不上时，这是最快的诊断入口。
顺手记在这里，免得后人（包括我自己）把它"简化"回去：
>=0.1.5-rc.1 <0.2.0-0 不是"任意 0.1.x"。semver 规定：预发布版本只能被同一 major.minor.patch
且自身带预发布标识的比较器放行——所以这条范围只覆盖 0.1.5-rc.1/2/3，0.1.6-* 与 0.1.7-* 全被排除
（已用 semver 库实测：maxSatisfying = 0.1.5-rc.3）。>=0.1.0-rc.8 <0.2.0 会只剩 0.1.0-rc.8 一个版本——这正是 dsh-lsp-actions 记录过的
"broke fresh tarball installs"。>=0.1.5-rc.1 <0.2.0 || >=0.1.6-0 <0.1.7-0 || >=0.1.7-0 <0.1.8-0。
注意每条带止于下一个 minor：写成 <0.2.0 会让它悄悄囊括还未验证的 0.1.8+。@deepseek-ai/dsh-home-paths 的 latest dist-tag 是过期的旧版本（0.0.1-rc.3），无范围的安装会解析到化石版本。验证方法（要加新版本时照做）：换 CLI 不够——插件从自己的安装位置解析依赖，所以必须同时让插件拿到那个版本的依赖树（例如在一个独立的 home 里，用该版本的 CLI 启动，并把依赖树一并指向该版本）。判据不能只看"能不能起来"，要看依赖层是否真的换了：本插件在 /health 里报告 layout.dshCachePathExported，它在 0.1.5 上应为 false、在 0.1.6+ 上应为 true——如果与目标版本不符，说明插件拿到的仍是旧依赖，这次验证不算数。
引用关系只认结构化字段，不在日志文本里搜哈希。 判定相对于"这一批保留下来的东西"，并遵循一条硬规则：
只要有任何一个会话的引用关系读不出来，「孤儿附件」这一档就整体暂停。
宁可少删，不可删错。完整的分档判定规则、安全保证与已知边界见 docs/safety.md。
不清理日志 / 临时文件 / 备份目录；不管理 profiles/ 下的插件依赖；不做定时自动清理；不允许模型替用户删数据；不支持远端 / 共享存储后端。
上面这些不是设计目标，而是已经实现的行为：所有破坏性操作都要人在界面上明确确认，Agent 侧只有只读工具。