[BUG] Shell cwd silently lost when a foreground command is auto-backgrounded — no 'Shell cwd was reset' notice emitted

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

The Bash tool's persistent shell is silently discarded when a long-running foreground command is auto-backgrounded (and, apparently, on timeout-kill and session resume). The replacement shell starts at the project root, so any cd state is lost — with no notification whatsoever.

This is inconsistent with the other way cwd can reset: when a command ends with the shell outside the project scope, the tool result explicitly appends Shell cwd was reset to <dir>. The shell-replacement path emits nothing, even though the harness has the same information. The agent (and user) cannot detect that subsequent commands are running in the wrong directory.

The auto-background notice says only:

Command running in background with ID: xxxxx. Output is being written to: .../tasks/xxxxx.output. You will be notified when it completes.

...and the next foreground command runs at the project root with no marker of any kind.

Note this is distinct from #67725 / #72339, which report cwd failing to persist between every call. Here persistence works correctly; the problem is the silent loss of the shell on auto-backgrounding, and specifically the missing notification.

Real-world impact

Mined my transcripts across one project: 8 wrong-directory incidents in 4 days, all traceable to this. Typical pattern: agent cds into a git worktree, runs a long test/review command, the command gets auto-backgrounded, and every subsequent command silently runs against the main checkout instead of the worktree.

Worst case observed: agent ran git stash in a worktree, a long test run got auto-backgrounded (discarding the shell), then git stash pop executed in the fresh shell — at the main checkout. Since worktrees share one stash stack, the pop restored the changes into the main working tree on the wrong branch. Nothing in any tool result indicated the directory had changed; the agent only noticed because git's output happened to say On branch main.

Sessions where agents review invalid results are also common: codex review / test harnesses silently running against the main tree (seeing no changes / wrong code) after an earlier command was backgrounded.

What Should Happen?

When the harness replaces the persistent shell (auto-background detach, timeout kill, session resume), the next Bash tool result should carry the same explicit notice already used for scope violations, e.g. Shell cwd was reset to <project root> — ideally with the reason (previous command moved to background). Preserving the cwd into the replacement shell would be even better, but the notification alone lets agents recover.

Steps to Reproduce

1. In any repo, run a Bash tool call: cd <repo>/some/subdir && pwd → persists as expected (verify with a second call: pwd shows the subdir).
2. Run a foreground command that exceeds the timeout so it gets auto-backgrounded, e.g. while true; do :; done with a short timeout — tool result: "Command running in background with ID: ...". No mention of the shell.
3. Run pwd → prints the project root. No Shell cwd was reset notice, no marker of any kind.

Contrast with: cd /tmp && pwd (outside project scope) → tool result correctly appends Shell cwd was reset to <project root>.

Environment

• Claude Code 2.1.187, macOS (darwin 25.5.0), zsh
• No CLAUDE_BASH_MAINTAIN_PROJECT_WORKING_DIR set; default cwd-persistence behavior otherwise verified working