[bug] 会话 workspace 目录被移动后，bash/grep/glob 全部持续 spawn ENOENT，且报错不指向真实原因

[webkubor]

环境

• @deepseek-ai/dsh 0.1.0-rc.6（dsh web，macOS，Node 24.15）
• 会话 workspace：~/dev/github/plugin

复现步骤

1. 在某个目录下启动 dsh web（进程 cwd 所在目录）
2. 会话进行中，把该目录（或进程 cwd 所在的子目录）移动/重命名到别处
   —— 我的操作：~/dev/github/plugin/dsh-bloom-theme → ~/dev/github/theme/dsh-bloom-theme
3. 此后所有需要派生子进程的工具全部失败：

Error: spawn bash ENOENT                     （bash 工具，含最简单的 echo）
Error: ripgrep launch failed                 （grep 工具）
Error: glob could not start its search command (ripgrep launch failed)  （glob 工具）

4. 进程内工具（read / write / edit）一切正常 —— 说明只是派生子进程的路径坏了
5. 多次重试（间隔数分钟）均失败，无自愈；只能重启会话/服务恢复

根因（已确认，非假设）

会话 workspace 目录被移动/删除后，bash 等工具以 workspace 为默认 cwd 派生子进程，
cwd 不存在时 spawn 报 spawn bash ENOENT —— 错误指向子进程名，极具误导性
（bash 明明在 /bin/bash 好好的）。grep/glob 依赖的 ripgrep 同理。

决定性证据：重建 workspace 目录（在原路径放一个占位文件）后，未重启任何进程，
bash 工具下一次调用立即恢复。此前重启 dsh web 守护进程（launchctl bootout +
bootstrap）无效 —— 说明坏的是会话绑定的 workspace 路径，不是服务进程自身的 cwd。

Workaround（立刻可用）

mkdir -p <会话的原 workspace 路径>   # 里面放个占位文件即可

无需重启会话，下一次工具调用即恢复。

为什么这个问题对用户高频

开发中随手整理目录结构（mv / 重命名项目文件夹）是很常见的操作，而 DSH 会话
往往一开就是几个小时。只要会话进程的 cwd 在被移动的目录树里，整个会话的
执行层就悄悄瘫痪，且报错完全看不出与目录移动有关（用户会以为 bash/环境坏了）。

建议

1. spawn 时显式传 cwd：校验 workspace root 存在后传入；不存在则回退
   os.homedir() 或 os.tmpdir()，而不是让子进程继承一个已失效的 cwd
2. 错误可诊断：ENOENT 且二进制绝对路径存在时，检测 process.cwd() 是否
   还挂载，给出可操作的报错，如「会话工作目录已被移动，请重启会话或……」
3. 自愈：定期检查 cwd 有效性，失效时 re-chdir 到 workspace root 或用户主目录

补充

• 时间线证据：目录移动发生在 12:14-12:15，首批 ENOENT 出现在其后的第一次工具调用；期间一次 echo 成功后随即全部失败（可能是移动完成过程中的竞态窗口）
• 愿意提供 DSH_LOGS / 更多复现细节

[denial123789]

I turned this reproduction into a source-backed operator runbook: https://sandbaseai.github.io/deepseek-harness-handbook/workspace-moved-spawn-enoent.html

The key diagnostic distinction is useful: spawn bash ENOENT does not prove that Bash is missing. At rc.7, the Bash tool derives its default workdir from session.header.cwd, and the local executor passes that value as the child-process cwd; the upstream executor test also confirms that a nonexistent workdir rejects with ENOENT.

One safety refinement to the immediate workaround: recreating the old path as an empty directory is a good pwd-only diagnostic, but it should not be treated as project recovery. A succeeding Agent command could then run without the expected repository files, instructions, lockfiles, or policy context. For continued work, move the complete project back, use a carefully validated compatibility symlink, or start a fresh Session at the new canonical path.

The guide links each claim to the pinned rc.7 source and includes a minimal incident evidence template. Thanks for the precise reproduction.