Regression: Bash tool permanently broken when CWD is deleted mid-session (was fixed in #21580 / #26136, returned in 2.1.119)

Resolved 💬 4 comments Opened Apr 24, 2026 by huntson Closed Apr 24, 2026

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:

  1. mkdir /tmp/cwd-repro && cd /tmp/cwd-repro
  2. Start Claude Code: claude
  3. Ask the agent: "run rm -rf /tmp/cwd-repro then ls"
  4. The rm succeeds. The ls (and every Bash call after it, forever) returns:

Working directory "/tmp/cwd-repro" no longer exists. Please restart Claude from an existing directory.

  1. 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 -rf on a path that contains cwd (the canonical repro from #26136).
  • git worktree remove when 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.

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗