[Windows] Web UI 启动后"内测声明"确认保存失败：safe-delete trash 操作报错

[1424249962]

Windows 上首次 Web UI 启动踩坑：内测确认状态保存失败（safe-delete / trash 报错）

提交地址：https://github.com/deepseek-ai/deepseek-harness/discussions/new
建议分类：Q&A（如选不到 Q&A 可选 General）
标题建议：[Windows] Web UI 启动后同意"内测声明"一直报"暂时无法保存确认状态，请重试"（safe-delete trash operation aborted）

背景

通过官方推荐的 npx @deepseek-ai/dsh web 安装（版本 0.1.0-rc.6），Node v22.22.2，npm 10.9.7，Windows 11（10.0.26200）。服务正常起在 http://127.0.0.1:3080。

进入页面后弹出「内测声明」对话框，点击「继续」后始终失败。

现象

• 对话框内出现红色提示：「暂时无法保存确认状态，请重试。」
• 始终卡在这一步，配模型、选工作区都无法用

服务端实际响应（前端抓取）

RPC settings.mutate 返回：

{
  "type": "server-response",
  "result": {
    "ok": false,
    "error": {
      "code": "settings-rejected",
      "message": "[safe-delete] 操作失败: ERROR C:\\Users\\18090\\.dsh\\settings.yaml.lock: Error during a `trash` operation: Unknown { description: \"Some operations were aborted\" }",
      "details": { "ns": "ui-onboarding" }
    }
  }
}

关键观察

C:\Users\<user>\.dsh\settings.yaml 实际已被正确写入，内容为：

ui-onboarding:
  welcomeNoticeVersion: 2026-08-13.1

也就是说：文件写入本身没问题。失败发生在 DSH 在写完之后执行的 "safe-delete" 操作（把旧的 settings.yaml.lock 扔进回收站），Windows 上的 trash 操作抛出 Some operations were aborted，导致整个 RPC 被判定为失败。

已排除的因素

• 换系统 Chrome / Edge 直接访问（排除内置预览面板存储限制）
• 重启 dsh 服务后重试（仍复现）
• 检查 C:\Users\<user>\.dsh 目录可写，正常读写
• settings.yaml.lock 当前不存在（锁文件已被处理，仍报 trash 失败）

推测根因

• Windows 上 DSH 使用的 trash 实现（疑似基于 Windows 回收站 / Shell API）在我的环境下不可用或被安全软件拦截
• "配置确认写入"这一步与"删除锁文件到回收站"耦合较紧——safe-delete 失败导致 settings.yaml 已成功写入的确认被整体拒绝

临时绕过

• dsh --profile headless "任务"（CLI 模式）不受影响，可以正常启动，仅在缺 DEEPSEEK_API_KEY 时提示配置
• 所以现在用 CLI 模式先用着，等

建议

1. 排查 Windows 平台 trash 操作失败原因（兼容性 / 回退策略）
2. 考虑在 safe-delete 失败时降级为 fs.unlink，或允许配置跳过 safe-delete
3. 若 onboarding 确认写入已成功，即使清理锁文件失败也不应返回 ok: false

---

Reported on 2026-08-14, dsh 0.1.0-rc.6 (developer preview), Windows 11.

[PerryLink]

你的观察是对的，但那个 [safe-delete] 不是 DSH 的——我在你那个版本上证实了这一点

1. 先肯定你的取证

你抓到的两点非常关键，而且都成立：

• ~/.dsh/settings.yaml 确实被正确写入了（ui-onboarding: welcomeNoticeVersion: 2026-08-13.1）；
• 失败发生在写完之后的一次删除操作上，目标正是 settings.yaml.lock。

所以这不是"写不进去"，而是"写成功了，但收尾那一步失败，于是整个 RPC 被判为失败"。你的判断方向是对的。

2. 但那一步不是 DSH 做的——这一点可以在你自己的版本上核实

我按你给的版本（0.1.0-rc.6）去查了那一版的实际源码，结果：

检查项	结果
字面量 safe-delete 出现在多少个文件里	0（rc.6 那一版、rc.7、rc.8、以及当前最新 0.1.7-rc.1，都是 0）
lockfile 里有没有 trash / safe-delete 这类依赖	没有
DSH 自己的原子写怎么删锁	普通 fs.rm(lockPath, { force: true })——直接删，不走回收站

（顺便提醒：如果你自己在源码里 grep trash，会命中十来个文件，但那些全是垃圾桶图标——IconTrashOutline16、ic_ds_trash_outline_16 之类。这也是我最初看过一眼后误判的原因。）

3. 那它是谁

[safe-delete] 操作失败: … 这个形状是插件命名空间前缀（[<插件名>] 消息）；而 Error during a \trash` operation: Unknown { description: "Some operations were aborted" }是 **Rust 风格**的错误渲染，正是原生 trash 实现（npm 上trash` 那一族）的典型输出。

⇒ 你的 profile 里有什么东西在对 settings.yaml.lock 做"安全删除/送回收站"。 可能是你装过的第三方插件，也可能是本地改过的安装。

4. 怎么把它揪出来（不启动也能查）

dsh --profile web --dump-config

这个命令只解析 YAML、不导入插件，所以卡在内测声明时也能跑。输出里每条 # == <label> 注释会写明那一行是哪个文件贡献的——重点看不是 @deepseek-ai/* 的那些条目。另外看一眼 ~/.dsh/profiles/web/package.json 的 dsh.profile.bundles 与 dependencies。

5. 关于"升级能不能解决"

我不打算承诺"升级就好"，因为那个操作不是 DSH 的代码做的——如果是插件导致的，升级不会动它。但两件事仍然值得做：

1. 先试一次刷新：值已经落盘了，界面重新读取后有可能直接放你过去（这一步最快，且能验证"只是响应被判失败"）；
2. 然后升级（你现在 0.1.0-rc.6 已经很旧）：注意别装 latest（npm 上它还停在 0.1.5-rc.3），用

   npm i -g @deepseek-ai/dsh@next      # 当前 = 0.1.7-rc.1
   

3. 如果升级后仍然报同样的 [safe-delete]，那就等于确认了是插件/本地改动——把上面第 4 步的清单贴出来，就能定位到具体是谁。