[BUG] Session working directory becomes permanently unresolvable after using a git worktree (background job), breaking Bash, file tools, and the /cd command

Environment:

• macOS (default Terminal app)
• Claude Code CLI, running as a background job (~/.claude/jobs/...)
• Project opened at /Users/n/Desktop/code/1shot-bench (a git repo with a sibling project at /Users/n/Desktop/code/pi-bench, not iCloud-synced, not on a network mount — confirmed local APFS)

Steps to reproduce:

1. Start a background-job session in a project directory.
2. Call EnterWorktree (or otherwise cause the harness to isolate work into .claude/worktrees/<name>).
3. Work normally in the worktree for a while (file edits succeed).
4. At some point, Bash commands — even trivial ones like echo test — start failing with:

``
This command was blocked because its working directory is spelled in a form that cannot be
safely resolved (for example through a symlink storing a raw dot segment, a network-share or
device-namespace shape, or an unreadable ancestor directory). If the directory is inside the
worktree <path>, re-run the command from its direct symlink-free path.
``

1. Read/Write tool calls on files under the same worktree path (and its corresponding main-checkout path) separately start failing with EPERM: operation not permitted, open '<path>'.
2. A full restart of both the Terminal app and Claude Code does not clear the issue.
3. Calling ExitWorktree (action: "keep") reports success ("Session is now back in /Users/n/Desktop/code/1shot-bench"), but the next Bash command's output includes an unprompted note: Shell cwd was reset to /Users/n/Desktop/code/1shot-bench/.claude/worktrees/<name> — i.e. the shell snaps back to the worktree path on its own.
4. getcwd()-based resolution is specifically broken: /bin/pwd consistently fails with pwd: .: Operation not permitted, while absolute-path commands against the same directory (stat -f "%N %p" <path>, which reports a completely normal drwxr-xr-x, correct owner) succeed, and cd <path> itself reports success with no error.
5. Access to a sibling directory outside the project root (/Users/n/Desktop/code/pi-bench) was initially readable via absolute-path ls, then later consistently denied (Operation not permitted) for the rest of the session — despite normal Unix permissions confirmed via stat. This narrowing appears correlated with the worktree enter/exit calls above.
6. Confirms it's not tool-specific: using the CLI's own built-in /cd slash command reproduces related breakage — /cd ../pi-bench resolved against the stale worktree path (.../.claude/worktrees/pi-bench) instead of the actual current directory, reporting "Couldn't find a directory" there. After /cd ../../../../.. successfully reached /Users/n/Desktop, subsequent /cd code and /cd code/pi-bench both failed with "the directory may no longer exist, or the session couldn't be moved" — even though /Users/n/Desktop/code is confirmed to exist and be a normal local directory.

Expected: Working directory resolution (pwd, Bash tool commands, Read/Write, /cd) should track the session's actual current directory reliably, and ExitWorktree should fully and durably return the session to the original directory.

Actual: Once this state is triggered, the session's notion of "current directory" appears to desync from reality in a way that (a) resists ExitWorktree, (b) resists a full app/terminal restart, and (c) causes both tool-level (Bash/Read/Write) and built-in (/cd) path resolution to fail or resolve against a stale/incorrect path.

Impact: Once triggered, the session becomes unable to reliably run any shell command or reference any file path for the remainder of the session — no in-session recovery found.