macOS: background/fleet session re-hosted onto a fresh spare worker loses live file access (EPERM) mid-session, after the bundle-ID fix (#61314)

Feedback ID (internal session telemetry cross-reference): 60d49143-d51c-4d96-a4c8-35fd4a90ee87

Summary

#61314 gave the background-agent helper a stable bundle ID, which fixed the upgrade re-grant churn for several TCC categories (Accessibility, Screen Recording now show com.anthropic.claude-code). Two related failures remain:

1. A long-running background session is re-hosted onto a fresh "spare" worker process mid-session (on MCP reload, version upgrade, or fleet recycle). The new worker is a new TCC principal that is NOT on the com.apple.macl access list of files the previous worker created, so it gets EPERM: operation not permitted on read and write of those existing files, while creating brand-new files in the same directory still works. No permission prompt appears; Read/Edit/FileHistory just fail.
2. FDA (SystemPolicyAllFiles), Microphone, and Documents-folder grants are still keyed to the versioned path, not the bundle ID. Microphone has no com.anthropic.claude-code bundle entry at all, so voice access still churns per update even though Accessibility/Screen Recording no longer do.

Distinct from #61314 / #49282 (the upgrade prompt); this is the mechanism behind the symptom in #62510 (EPERM cascade in long sessions).

Steps to Reproduce

1. On macOS, run a long-lived background/agent session with a project under a TCC-protected folder (~/Documents).
2. Have the session create/append a file (e.g. a log).
3. Trigger a re-host of the session worker: install a new MCP and reset the session to load it, let an auto-update land, or let the fleet recycle the worker.
4. After the re-host, read or append to the file created earlier. It fails with EPERM: operation not permitted. Creating a NEW file in the same folder still succeeds.

Process Tree / Daemon Evidence

Daemon re-hosting the session onto pooled spare workers, and an in-flight upgrade re-adopting sessions onto fresh workers (from ~/.claude/daemon.log):

[bg] bg claimed-spare <session-id> (fleet)
[supervisor] binary changed (versions/2.1.177 -> versions/2.1.178) self-restarting for upgrade
[supervisor] daemon start version=2.1.178
[bg] bg adopt: adopted=4 respawned=0 dead=0

The worker is a pooled spare (note /spare/ in the socket path):

.../ClaudeCode.app/Contents/MacOS/claude --bg-pty-host
    /tmp/cc-daemon-<uid>/<id>/spare/<id>.pty.sock -- versions/2.1.178 --resume <session-id>

Symptom: cp, xattr, Read, and Edit on the existing file all return EPERM; the file carries com.apple.macl + com.apple.provenance from the prior worker; no process holds it (lsof empty); brctl confirms the path is not iCloud.

TCC State (residual path-keying after #61314)

System db kTCCServiceSystemPolicyAllFiles: four versioned-path entries (.../versions/2.1.160|161|162|178) alongside the bundle entry. Per-user db: kTCCServiceMicrophone, kTCCServiceSystemPolicyDocumentsFolder, kTCCServiceAppleEvents still have versioned-path entries; Microphone has only path entries + the desktop bundle, no claude-code bundle.

Impact

• Silent mid-session data loss: a session loses access to files it itself created, no prompt, opaque tool error. Overnight/agent-fleet and long autonomous runs are worst hit (the #62510 cohort).
• Voice still churns: Microphone is path-keyed with no bundle entry, so voice access breaks on every update even post-#61314.
• Granting FDA does not reliably help a re-hosted worker, because the block is per-file (macl) tied to the creating process, not just folder FDA.

Expected Behavior

A re-hosted worker should retain access to files created earlier in the same session. TCC identity should follow the session, not the ephemeral worker process, and all TCC categories should attribute to the stable bundle ID.

Fix (suggestions)

1. Extend #61314's bundle-ID attribution to the remaining categories (FDA, Microphone, Documents, AppleEvents) so no TCC service falls back to the versioned path. Microphone in particular has no claude-code bundle entry.
2. For the per-file macl loss: run re-hosted spare workers under the same responsible-process / stable bundle identity so they inherit the session's existing grants, OR route protected-folder file I/O through the stable daemon (which holds the bundle grant) instead of the ephemeral worker.
3. Fail loud: detect EPERM on session-created files and surface "file access lost on worker re-host; re-grant Claude Code Full Disk Access" instead of an opaque Read/Edit/FileHistory failure.

Environment

• macOS 26.x (Darwin 25.3.0), Apple Silicon
• Claude Code 2.1.178 (background/fleet session, --bg-spare / --bg-pty-host)
• Project under ~/Documents
• Related: #61314 (fixed, bundle ID), #62510 (symptom), #49282 / #30608 / #67045