macOS: session-wide filesystem access (Bash cwd + Read tool) permanently breaks with EPERM after git worktree remove on a directory the session had cd'd through

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (closest matches are #82691 and #82666 — both related but a different mechanism, see below)
• [x] This is a single bug report
• [x] I am using a recent version of Claude Code

What's Wrong?

Mid-session, after several git worktree remove calls had already succeeded normally over the course of a long session, one more git worktree remove call on a merged, already-pushed worktree started failing:

fatal: Unable to read current working directory: Operation not permitted

This did not resolve on retry, on cd-ing to a different, valid, existing directory first (in the same command), or with the sandbox explicitly bypassed for that one call. Diagnosis showed bash's own logical pwd builtin still printed a plausible-looking path, but the real kernel-level cwd was broken for every subsequent command in that persistent shell — including Apple's own /bin/pwd and plain ls on an unrelated, valid directory:

$ /bin/pwd
pwd: .: Operation not permitted

$ ls -la ~/some/valid/directory/
ls: ~/some/valid/directory/: Operation not permitted

$ node -e "console.log(process.cwd())"
Error: EPERM: process.cwd failed with error operation not permitted, uv_cwd

Commands that don't need local filesystem access (gh api, gh pr view, etc.) kept working fine throughout — only local git/node/fs operations broke, and they broke completely, not intermittently.

Escalation — the part I haven't seen reported elsewhere: in a later conversational turn of the same session, the dedicated Read tool (a separate code path from the Bash tool's persistent shell) also started failing with EPERM, on files completely unrelated to the removed worktree:

EPERM: operation not permitted, open '/Users/.../totally/unrelated/file.md'

At that point the entire session had lost all filesystem-tool functionality. No in-session recovery was possible (fresh cd, --force flags, explicit sandbox bypass all failed identically); a brand-new session was required to continue.

What Should Happen?

• git worktree remove on a worktree the session isn't currently "inside" (or that no other in-flight command depends on) should not corrupt the shell process's cwd for all future commands.
• If the shell process's cwd does become unresolvable, the harness should detect this and re-anchor it (some self-recovery already appears to exist elsewhere in the harness, e.g. the "Shell cwd was reset to X" message shown after a worktree directory disappears — but in this case that recovery message fired and the shell's real cwd remained broken afterward).
• The Read tool's file access should not be coupled to the Bash tool's shell cwd state — a broken Bash shell cwd should not be able to break the Read tool for unrelated absolute paths.

Steps to Reproduce

1. In a long-running session on macOS, create and use several git worktrees via git worktree add (in this case, via the documented multi-repo worktree workflow — enter a worktree, do work, push, exit).
2. Successfully git worktree remove at least one already-merged worktree (this worked fine earlier in the same session).
3. Later in the same session, git worktree remove a different worktree (also already merged and pushed) that the session had at some point cd'd into (directly or via the harness's own worktree-entry mechanism).
4. Observe fatal: Unable to read current working directory: Operation not permitted.
5. Observe that /bin/pwd, ls <any-directory>, and node -e "process.cwd()" all now fail identically for the rest of the session.
6. In a later turn, observe the Read tool also failing with EPERM on arbitrary, unrelated files.

Error Messages/Logs

See above — fatal: Unable to read current working directory: Operation not permitted (git), pwd: .: Operation not permitted (/bin/pwd), EPERM: process.cwd failed with error operation not permitted, uv_cwd (Node), EPERM: operation not permitted, open '<path>' (Read tool).

Is this a regression?

Unknown.

Platform / Operating System

macOS (Darwin 25.6.0), Claude Desktop app, multi-repo project with several git worktrees in active use across concurrent sessions.

Related

• #82691 — very similar error text (Unable to read current working directory: Operation not permitted), but that report's diagnosis (via the correction comment) narrowed to a different mechanism: a per-binary sandbox denial specific to git at hook-subprocess spawn time on the + New/LocalSessions.start path, with ls//bin/pwd/bash's own pwd builtin all unaffected, and the trigger being session/worktree creation via a configured hook. This report's trigger is mid-session git worktree remove, every binary (including /bin/pwd) broke, and it escalated into the separate Read tool — none of which matches #82691's established mechanism, so filing separately rather than commenting there.
• #82666 — similar EPERM-on-TCC-workspace symptom, but explicitly "intermittent" and "self-recovers in ~5-35 min." This session's breakage did not self-recover across multiple subsequent turns.

If a maintainer determines this is the same underlying issue as #82691 or #82666 after all, happy to have this closed as a duplicate — flagging the mechanism differences above since they didn't look like a clean match on read.