[BUG] macOS: auto-update deletes the running app bundle mid-session, revoking granted Full Disk Access until restart

Summary

On macOS, when Claude Code auto-updates while a session is running, the updater deletes the currently running version's application bundle from ~/Library/Application Support/Claude/claude-code/<version>/claude.app. The live process is left executing from a bundle that no longer exists on disk. macOS then stops honoring the Full Disk Access grant for that process, and all file operations on TCC-protected locations (Downloads, Documents, Desktop, iCloud Drive) begin failing with Operation not permitted — silently, mid-session, with no error identifying the cause. A full quit and relaunch restores access.

Environment

• Claude Code running under Claude Desktop
• Version transition observed: 2.1.181 → 2.1.187 (auto-update during an active session)
• macOS 27.0 (build 26A5368g), Apple Silicon (arm64)
• Inner bundle identifier: com.anthropic.claude-code; host app: com.anthropic.claudefordesktop (Team Q6L2SF6YDW)
• Full Disk Access had been granted to Claude and working for ~120 days prior

Steps to reproduce

1. Grant Claude Full Disk Access. Confirm a Claude Code session can read a protected folder (e.g. ls ~/Downloads).
2. Keep that session running.
3. Allow (or trigger) a Claude Code auto-update to a new version while the session is still open.
4. The updater removes the previous claude-code/<old-version>/ bundle.
5. In the still-running session, run a file operation against a TCC-protected directory.

Actual behavior

• ls ~/Downloads → Operation not permitted (EPERM). Same for ~/Documents, ~/Desktop, and iCloud Drive.
• A non-protected directory (e.g. the project working directory) still reads fine.
• The failure persists even with the per-command shell sandbox disabled — i.e. it is OS-level TCC, not the Claude Code sandbox or Claude Code's own permission layer (which were fully permissive).
• The running process is executing from a bundle path that no longer exists on disk:
• Process path: ~/Library/Application Support/Claude/claude-code/2.1.181/claude.app/Contents/MacOS/claude
• On disk: only …/claude-code/2.1.187/ exists (created at the time of the update); the 2.1.181 directory returns "No such file or directory".

Expected behavior

• An in-session auto-update must not delete the bundle of the running process.
• Permissions granted to the running process (Full Disk Access) must remain in effect for the life of that process.

Impact

• Silent, mid-session loss of file access on the user's primary folders; Read/Write tools begin failing.
• Naturally misattributed by the user to their own macOS privacy settings (Full Disk Access appears granted, yet access fails), sending them to debug the wrong thing.
• Any auto-update landing during an open session can reproduce it.

Suggested fixes

1. Never delete the bundle of a running process. Defer removal of the old claude-code/<version>/ directory until no live process references it.
2. Stage updates; activate on restart. Download into a new path but keep the running version's bundle intact for the life of the process; switch over on next launch.
3. Run from a stable path (e.g. a …/claude-code/current symlink repointed atomically on restart) rather than executing directly from a version-stamped directory the updater later deletes.
4. Detect and surface the condition. If the running bundle's on-disk path disappears, show a clear notice ("Claude Code updated in the background; file access is suspended until you quit and reopen") instead of letting operations fail as unexplained Operation not permitted.

Workaround

Fully quit Claude (⌘Q — not just closing the window) and reopen. A fresh process runs the intact, signed on-disk bundle and the existing Full Disk Access grant applies again.

Possibly related

• #69546 — macOS: a hardcoded CLI version path breaks on every version bump (same version-stamped-path fragility).
• #69140, #66997 — auto-update deleting user data on Windows (same "auto-update removes things it shouldn't" family).