[BUG] Long-lived --bg-pty-host process caches revoked macOS TCC grants; /exit and new terminals reattach to it, so file access cannot be restored without killing the daemon

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?

Mid-session, every filesystem operation under ~/Documents began failing with Operation not permitted — ls, git, the Read tool, and subagents alike. /tmp, ~ itself, and Docker were unaffected; the block was specific to that subtree.

This was a regression within a running session: the session-start gitStatus block had successfully read that exact repo (branch, modified files, commit SHAs) minutes earlier. A macOS TCC "Files and Folders" grant lapsed while the session ran.

The trigger is unidentified. No OS update was applied, and while Claude Code auto-updated to 2.1.236 about 30 minutes earlier, the ClaudeCode.app bundle that TCC keys on was untouched for three days. Ruled out: a background workflow stopped at
00:22 — fifteen minutes after the block began.

The cause is the background PTY host:

PID 12711 started Mon Aug 17 22:29:05 (two days earlier)
~/.local/share/claude/ClaudeCode.app/Contents/MacOS/claude --bg-pty-host ...

macOS caches TCC decisions per process, at launch. That daemon is deliberately long-lived so sessions can reattach — so every restart reattached to a process still carrying the denial, and the new grant could never reach it. Access returned only after the daemon was killed and replaced.

The failure is silent and self-defeating: there is no signal pointing at the daemon, and the user's instinct (restart everything) is exactly what doesn't work.

What Should Happen?

Granting the permission and restarting Claude Code should restore file access.

Failing that, Claude Code should make the cause discoverable. Any one of these would
have been enough:

• On EPERM for a path that succeeded earlier in the same session, surface: "the

background host may be holding a stale permission grant — restart it with …"

• A documented command to recycle the PTY host.
• Have the host re-exec itself on a TCC denial so a fresh grant is picked up.

Error Messages/Logs

ls: /Users/mg/Documents/: Operation not permitted
fatal: Unable to read current working directory: Operation not permitted
PermissionError: [Errno 1] Operation not permitted   # coderlm, on os.getcwd()

$ ps -o pid=,lstart=,command= -p 12711
12711 Mon Aug 17 22:29:05 2026 /Users/mg/.local/share/claude/ClaudeCode.app/Contents/MacOS/claude --bg-pty-host

Steps to Reproduce

1. Start Claude Code and confirm it can read a TCC-protected location, e.g.

ls ~/Documents succeeds.

1. Cause the grant to lapse — an OS update, or revoke Files-and-Folders access for

the host app.

1. Observe Operation not permitted on paths that worked minutes earlier.
2. Grant Full Disk Access to ~/.local/share/claude/ClaudeCode.app.
3. /exit, relaunch, and try a new terminal window. Still blocked.
4. ps aux | grep bg-pty-host — note the PID predates the grant, often by days.
5. kill <pid>, then relaunch. Access restored.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

v2.1.236

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2 Build 3.6.11 (macOS)

Additional Information

Environment: macOS 26.5.2 (25F84), Claude Code 2.1.236 (2.1.233 when first hit),
iTerm2 3.6.11, zsh.

Note the diagnostic asymmetry: stat ~/Documents succeeded (the path resolves) while ls and any read failed — the directory entry is visible, contents are gated. That's the TCC signature, and it's what finally distinguished this from a missing directory or a Claude Code sandbox rule.