[Bug] Intermittent permission loss for project directories on macOS

This matches a cluster of open macOS reports that include more diagnostics:

• #88576: a running session loses ~/Documents shortly after the auto-updater installs a newer version. Native installs put each release at its own path (~/.local/share/claude/versions/<version>), and macOS keys folder permissions for a standalone executable by its path, so every release looks like a new app. #49282 and #80899 describe the same root cause through repeated permission prompts.
• #87061: a long session loses Downloads, then Documents, then its own working directory (getcwd EPERM). Relaunching fixes it.
• #90227: with the Bash sandbox on, tccd fails with "Failed to create Attribution Chain" and Documents access stays lost. One trigger was a command that deleted the shell's current directory.

Knowing which one you hit would tell the maintainers which report this belongs with. Next time it happens, before restarting, these checks should show it:

1. Did an update land during the session? Compare the version in /status with ls -lt ~/.local/share/claude/versions. A version newer than the session points to #88576. The native installer keeps only a few recent versions, so a long session can also be running a binary that has since been deleted.
2. What did macOS log? Use the full path, because zsh has its own log builtin:

``sh
/usr/bin/log show --last 30m --style compact --predicate '(process == "tccd" OR process == "sandboxd" OR process == "kernel") AND (eventMessage CONTAINS[c] "Documents" OR eventMessage CONTAINS "Attribution Chain" OR eventMessage CONTAINS "deny(1) file-read-data")'
`
A deny(1) file-read-data …/Documents line names the process that was denied. Failed to create Attribution Chain` points to #90227.

1. How far does it reach? Does the Read tool fail as well, or only Bash commands? Is the sandbox on (/sandbox)? Did a command just remove the shell's working directory, such as a worktree or a temp folder?

It would also help to know which terminal app you use, and whether Claude Code came from the native installer or npm.

Workarounds until there's a fix:

• Keep projects outside ~/Documents, ~/Desktop and ~/Downloads, the folders macOS protects this way.
• Or stop mid-session updates with "env": {"DISABLE_AUTOUPDATER": "1"} in ~/.claude/settings.json, and run claude update between sessions.

Im having the same issue exactly, for more than 2 months now, i have this issue on two different laptop, m1 and m5max on macOS 26.5, iTerm2

When it happens i can't even "ls" in the folder.. through iterm, and it is caused by claude for sure.. i actually have a markdown research of claude on why that happened on my laptop

Lately it has been happening more and more

@thepixelabs thanks, "even ls fails in iTerm2" is a useful detail. It matches #87061, where the kernel log showed a plain ls denied along with Claude Code (System Policy: ls(57439) deny(1) file-read-data …/Documents), and only quitting the terminal fixed it. That report was auto-closed for inactivity two days ago, so this issue is now the open one for this pattern.

When it next happens, before you restart anything, these would help narrow it down:

1. Where does ls fail? Run ls ~/Documents in the tab where Claude Code was running (after exiting it), and again in a brand-new iTerm2 tab. If only the old tab fails, access is lost for that one process tree. If the new tab fails too, iTerm2 as a whole has lost access.
2. The kernel and tccd log from the moment it breaks. Use the full path, because zsh's log builtin shadows the real command:

``sh
/usr/bin/log show --last 30m --style compact --predicate '(process == "tccd" OR process == "sandboxd" OR process == "kernel") AND (eventMessage CONTAINS[c] "Documents" OR eventMessage CONTAINS "Attribution Chain" OR eventMessage CONTAINS "deny(1) file-read-data")'
`
The deny(1)` lines name the processes that were denied.

1. Your Claude Code version and install type (native installer or npm), whether the Bash sandbox is on (/sandbox), and whether ls -lt ~/.local/share/claude/versions shows an update installed during the session.

If you can share the markdown research with usernames and paths removed, please add it here too. Findings from two different Macs would help the maintainers reproduce it.