macOS Desktop folder becomes unreadable from Terminal until reboot

Title: ~/Desktop becomes unreadable from the command line until reboot — only Desktop, FDA granted, no TCC denial logged

macOS 26.5.2 (25F84), Apple Silicon.

Every few days, ~/Desktop stops being readable from Terminal. ls ~/Desktop returns "Operation not permitted". A reboot fixes it, and it comes back hours to days later.

What makes it odd:

- Only Desktop. ~/Documents, ~/Downloads, ~/Pictures and ~ all list normally throughout.

- It's EPERM, not EACCES — so something above POSIX is refusing, on a directory I own with drwx------.

- Directory enumeration fails, individual files don't. opendir() fails via ls, shell globbing, find and os.listdir(). But stat on a file by explicit path works, and files in subdirectories of Desktop read and write normally. Over the course of one episode it degraded — early on I could still read and write top-level files, later only create new ones.

- Finder shows the Desktop perfectly the whole time, so the data and filesystem are fine.

What I've already ruled out:

- Terminal has Full Disk Access, and it's effective — the same shell can read /Library/Application Support/com.apple.TCC/TCC.db, which requires it.

- No deny entries in either TCC database. kTCCServiceSystemPolicyAllFiles is 2 (allowed) for Terminal, and there is no SystemPolicyDesktopFolder row denying anything.

- Nothing logged — log show --predicate 'subsystem == "com.apple.TCC"' produces no denials during an episode.

- Not a sandbox. sandbox_check(getpid(), NULL, 0) reports the process unsandboxed, and a per-path check returns allowed for Desktop.

- Permissions, ACL and flags are identical to ~/Documents, which works — same mode, same group:everyone deny delete, no flags.

- No system extensions installed. Nothing mounted on Desktop. Not an iCloud or third-party sync root.

- tccutil reset SystemPolicyDesktopFolder does nothing, which is consistent with TCC not being the thing denying.

So every policy layer I can inspect says access is permitted, and the kernel refuses anyway — which is why I assume stale cached authorization state for that vnode, and why a reboot clears it.

Has anyone seen this, and is there a way to clear it without rebooting? And is there somewhere other than the TCC subsystem I should be looking in the log to see what's actually issuing the denial?