Regression: Bash tool permanently broken when CWD is deleted mid-session (was fixed in #21580 / #26136, returned in 2.1.119)
Summary
This is a regression of #21580 ("Bash tool becomes permanently stuck when cached working directory is moved or deleted", closed COMPLETED 2026-02-20) and #26136 ("Deleting its CWD breaks its shell", closed COMPLETED 2026-02-16). Both were fixed in February 2026; the bug is back in Claude Code 2.1.119.
If the agent deletes the directory the harness is using as its Bash cwd, every subsequent Bash tool call returns:
Working directory "<path>" no longer exists. Please restart Claude from an existing directory.
The agent has no way to recover. cd /tmp && ls, absolute-path commands, pushd, /bin/bash -c '...' — all fail with the same error, because the harness validates cwd before handing the command to the shell. Read, Write, Edit, WebFetch, WebSearch, and subagents continue to work, proving the session itself is alive — but anything that needs a shell (tests, git, docker, pytest) is impossible for the rest of the session.
Steps to reproduce
Hits every time in a fresh session:
mkdir /tmp/cwd-repro && cd /tmp/cwd-repro- Start Claude Code:
claude - Ask the agent: "run
rm -rf /tmp/cwd-reprothenls" - The
rmsucceeds. Thels(and every Bash call after it, forever) returns:
Working directory "/tmp/cwd-repro" no longer exists. Please restart Claude from an existing directory.
- Ask the agent to
cd /tmp && ls. Same error — the harness refuses to spawn the shell because cwd validation runs before the command.
Expected
What #21580 and #26136 originally fixed: on ENOENT for cwd, fall back to a known-good directory (project root → $HOME → /tmp), update session cwd, and emit a one-line warning the agent can see ("cwd was removed; now running from /Users/…").
Actual
Every Bash call returns the "no longer exists" error until session restart.
Impact
Common real-world triggers:
- Agent is asked to "move this app into
~/projects/foo" and the repo being moved happens to be the cwd. - Any
rm -rfon a path that contains cwd (the canonical repro from #26136). git worktree removewhen cwd is the removed worktree (see related open issues #18236, #48405, and recently-NOT_PLANNED'd #34344).- Test suites that clean up tempdirs.
Environment
- Claude Code: 2.1.119
- OS: macOS 15.x (Darwin 25.3.0)
- Shell: zsh
Related
- #21580 (closed COMPLETED 2026-02-20, locked) — original canonical
- #26136 (closed COMPLETED 2026-02-16, locked) — sibling fix
- #18236 (open, worktree variant, no activity since Jan)
- #48405 (open, filed 2026-04-15, worktree variant) — likely the same regression scoped to worktrees
- #34344 (closed NOT_PLANNED 2026-04-14) — worktree variant declined 10 days ago, possibly mistakenly given that #21580/#26136 were marked completed
Proposed fix
The same fallback that landed for #21580/#26136: in the harness's pre-command hook that does chdir(session_cwd) before spawning bash, on ENOENT retry with project_root → $HOME → /tmp, update session_cwd to whichever succeeds, and emit a system-reminder so the model knows. One extra syscall on the error path; no change on the happy path.
4 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This regression matters because it traps the session in a partially alive but operationally crippled state. The agent can still read, write, and perform non-shell actions, but the entire shell-dependent toolchain becomes permanently unavailable for the rest of the session.
That is especially costly because shell access is not peripheral in coding workflows; it is how users run tests, inspect git state, use package managers, and recover from mistakes. Once a deleted cwd converts every future Bash call into an unrecoverable ENOENT gate, the user is forced into session restart even though the broader session context is still intact.
The report also does a strong job establishing regression status against prior completed fixes. That makes this more than a missing feature; it is a recovery guarantee that appears to have been lost again.
But it's not fucking completed.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.