工作区目录重命名后，失效 cwd 导致多套工具链不可用

[1515744558-jpg]

一句话说明：Web GUI 会话持久化了工作区的绝对路径；工作区在 DSH 外部被重命名或删除后，旧 cwd 仍被用于启动子进程和计算沙箱根目录，导致 bash、glob/grep、持久终端及沙箱出现连锁失败，而且会话内缺少可恢复入口。

复现、实际结果、预期与验收

环境

• DSH：@deepseek-ai/dsh 0.1.1-rc.2
• Surface：Web GUI
• 模型：z-ai/glm-5.3-flash
• 系统：macOS arm64
• File policy：workspace-write（期间切换过 danger-full-access）
• 会话记录的工作区：<old-workspace>（已在 DSH 外部重命名/删除）
• 实际项目目录：<new-workspace>（存在且可读写）
• ripgrep：14.1.1 arm64；直接执行正常

真实用户名和项目名已匿名化，不影响复现。

复现步骤

1. 在 <old-workspace> 创建并使用一个 Web GUI 会话。
2. 在 Finder 或终端中把该目录重命名为 <new-workspace>。
3. 回到原会话继续调用工具。
4. 调用 bash，不传 workdir：{"command":"true"}
5. 再调用 bash，显式传入存在的目录：{"command":"true","workdir":"<new-workspace>"}
6. 调用 glob/grep，并把 path 显式设为 <new-workspace>。
7. 在 workspace-write 下尝试写入 <new-workspace>，再按错误提示用 sandbox_permissions: "workspace-write" 重试。

实际结果

1. bash

• 不传 workdir：Error: spawn bash ENOENT
• 显式传入有效 workdir：成功

这表明 ENOENT 指向的是失效的子进程 cwd，而不是 bash 可执行文件缺失。

2. glob / grep

无论是否传入存在的 path，均失败：

• glob could not start its search command (ripgrep launch failed)
• grep could not start its search command (ripgrep launch failed)

同一台机器上直接运行 ripgrep、扫描项目目录均正常。推断 path 只作为搜索目标，启动 ripgrep 时仍使用了会话旧 cwd。

3. sandbox / workspace-write

• workspace-write 仍把 <old-workspace> 当成 workspace root，因此写入 <new-workspace> 被拒绝。
• 传 sandbox_permissions: "workspace-write" 又报：
  sandbox escalation to "workspace-write" is not strictly wider than this call's current "workspace-write mode"
• ask-policy 路径中，sandbox-exec 也出现 spawn sandbox-exec ENOENT；失效 cwd 会让 runner 启动失败看起来像可执行文件缺失。

结果是恢复死锁：受限模式不承认新目录，提示的同级升级又必然被拒绝。

根因判断

会话头和 workspace 状态保存的是绝对路径字符串。目录在 DSH 外部重命名后，DSH 没有收到迁移事件，也没有在会话恢复或 spawn 前校验 cwd 是否仍存在。

同一个失效值随后被多个消费者复用：

• bash 默认 workdir
• glob/grep 的 ripgrep spawn cwd
• persistent terminal 初始 cwd
• sandbox runner spawn cwd
• workspace-write 的 workspace root

所以表面上是多个工具同时损坏，实际上是一个过期的 session/workspace cwd 没有经过有效性检查和恢复流程。

当前 master（页面所示 b150a551）的 tool-fs-search 集成测试仍把 “unusable session cwd” 固定为 SEARCH_FAILED；如果产品预期是失败，也仍需要一个用户可见的重新绑定/恢复入口，否则旧会话无法自救。

预期结果与建议

工作区被移动、重命名或删除后，DSH 应明确提示“当前会话的工作区已失效”，并提供重新选择/重新绑定目录的操作；不应把 cwd 失效伪装成 bash、ripgrep 或 sandbox runner 缺失。

1. 会话加载以及每次 spawn 前验证默认 cwd 是否存在且可进入。
2. 若失效，返回结构化的 WORKSPACE_NOT_FOUND / INVALID_CWD 错误，带原路径和重新绑定指引。
3. Web GUI 提供“重新绑定工作区”入口，并同步更新 workspace、session header、policy root 和 session storage 索引。
4. glob/grep 在显式 path 有效时，不应仍被无关的旧 session cwd 阻断；至少应报告 cwd 与搜索目标分别是什么。
5. sandbox runner 启动失败时区分“runner 不存在”和“cwd 不存在”。
6. 拒绝提示只列真正更宽的模式：当前为 workspace-write 时，只建议 danger-full-access。

验收条件

• 重命名工作区后，原会话显示可理解的失效提示和重新绑定操作。
• 重新绑定后，无需手改状态文件或会话日志：
  • bash 不传 workdir 能运行；
  • glob/grep 能搜索新工作区；
  • persistent terminal 能启动；
  • workspace-write 允许新工作区、拒绝工作区外路径；
  • denial hint 不再建议非严格升级。
• 错误信息能区分 executable ENOENT 与 cwd ENOENT。

临时绕行

• bash：显式传入有效 workdir。
• glob/grep：用带有效 workdir 的 bash + rg 替代。
• workspace-write：新建绑定到新目录的会话，或手工迁移 DSH 状态；danger-full-access 只是临时绕行。

相关的同级升级讨论（本报告补充目录改名触发的完整故障链）：#2914、#3806。

[denial123789]

I turned this into a source-backed recovery runbook: https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/troubleshooting/renamed-workspace-stale-cwd.md — it separates stale session cwd from missing executables, maps the Bash/search/terminal/sandbox fan-out, and defines a safe atomic rebind contract. Published in v0.5.376: https://github.com/sandbaseai/deepseek-harness-handbook/releases/tag/v0.5.376

[1515744558-jpg]

thank-you 

…

---原始邮件--- 发件人: ***@***.***> 发送时间: 2026年8月29日(周六) 凌晨3:30 收件人: ***@***.***>; 抄送: ***@***.******@***.***>; 主题: Re: [deepseek-ai/deepseek-harness] 工作区目录重命名后，失效 cwd 导致多套工具链不可用 (Discussion #4953) I turned this into a source-backed recovery runbook: https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/troubleshooting/renamed-workspace-stale-cwd.md — it separates stale session cwd from missing executables, maps the Bash/search/terminal/sandbox fan-out, and defines a safe atomic rebind contract. Published in v0.5.376: https://github.com/sandbaseai/deepseek-harness-handbook/releases/tag/v0.5.376 — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>