Worktree-isolated session: `/cd <repo root>` makes every later Bash call refused as "working directory resolved to the shared checkout", and the refusal does not name the recovery

Bug description. In a session that has run EnterWorktree, running the desktop app's /cd <repository root> moves the session cwd to the shared checkout. From then on every Bash call is refused with "this command's working directory resolved to the shared checkout (…). Refusing to run it there — a worktree-isolated session's commands must run inside its worktree. Re-run the command from <worktree>." That includes commands that begin with cd <worktree> && …, because the check runs on the session cwd before the command is parsed. The suggested remedy ("re-run the command from <worktree>") cannot be applied by the model: a shell cd does not change the session cwd. The working recovery is EnterWorktree with path=<worktree>, which the refusal never mentions. Four consecutive refusals in 24 s before the model found it.

Expected. Either (a) honour a leading cd <this session's worktree> && prefix when the rest of the command stays inside the worktree, or (b) keep refusing but say: "run EnterWorktree with path=<worktree> to return the session cwd to its worktree". (b) is the smaller change and removes the dead end.

Repro. EnterWorktree name=x → user runs /cd <repo root> → cd <repo>/.claude/worktrees/x && git status → refused as above.

Environment. darwin, Claude desktop app (Code tab), Claude Code 2.1.293. Session dc061e3f-982d-4c65-9281-800e27c0ee2c, 2026-10-10 12:17 UTC.

Related, not duplicates. #98709 (a leading cd <dir> && is normalised against the recorded session cwd; there it is dropped rather than refused), #91932 (the Bash cwd pin does not follow EnterWorktree), #84704 (EnterWorktree path= inside a sub-agent reports success but Bash stays pinned). This report is the user-typed /cd in a top-level session.