[BUG] macOS: opening the agents view (left arrow) fires a "Data Access Blocked" notification every time, attributed to "2.1.250" instead of Claude Code
Summary
On macOS, every time I open the agents view (left arrow key from the main REPL), macOS fires a "Data Access Blocked" notification:
Data Access Blocked "2.1.250" tried to access your data from other apps and was blocked. You can manage this at any time in Files & Folders settings.
It happens on every single open of the agents view, so it's a notification every few minutes during normal use.
Two problems here:
- Opening the agents view is reaching into a TCC-protected location it presumably doesn't need (or isn't handling the denial gracefully).
- The notification identifies the app as "2.1.250" — the raw version number — instead of "Claude Code", which makes it impossible for a user to know what's asking, and the Files & Folders settings pane lists it under that same meaningless name.
Steps to reproduce
- Install/run the native macOS CLI (
~/.local/bin/claude), fresh install, no Full Disk Access granted. - Start
claudein any directory. - Press the left arrow key to open the agents view.
- macOS notification appears immediately.
Repeats every time the view is opened.
Expected
Either the agents view doesn't touch other apps' data containers at all, or — if it legitimately needs to (e.g. to discover sessions from Claude Desktop / other clients) — the access is guarded and the denial handled silently, with no OS notification spam.
And whatever the app requests, it should identify itself as Claude Code, not as a version string.
Why it says "2.1.250"
The launcher on PATH points at a bare, un-bundled Mach-O whose filename is the version:
$ ls -la $(which claude)
/Users/me/.local/bin/claude -> /Users/me/.local/share/claude/versions/2.1.250
$ file /Users/me/.local/share/claude/versions/2.1.250
Mach-O 64-bit executable arm64
There is a proper app bundle shipped alongside it, but nothing on PATH uses it:
~/.local/share/claude/
├── ClaudeCode.app/Contents/MacOS/claude <- proper bundle identity
└── versions/2.1.250 <- what `claude` actually runs
Both binaries carry the same signature (Identifier=com.anthropic.claude-code, TeamIdentifier=Q6L2SF6YDW), but since the process on PATH is executed as a loose file rather than through the bundle, TCC has no Info.plist/CFBundleName to read and falls back to the filename — hence "2.1.250".
That also means the TCC grant is pinned to a version-named path: any permission the user grants in Files & Folders is likely to be orphaned on the next auto-update, since the next version is a differently-named file, and the settings pane accumulates one entry per version.
Note also that codesign -dv reports Info.plist=not bound and Sealed Resources=none for the app bundle itself.
Suggested fixes
- Don't have the agents view touch other-app data containers, or wrap the access so a TCC denial is a silent no-op.
- Execute via
ClaudeCode.app(or make thePATHentry a stable, non-versioned name) so the app identifies itself as "Claude Code" and TCC grants survive updates.
Environment
- Claude Code: 2.1.250 (native installer, arm64)
- macOS: 27.0 "Golden Gate" beta 7 (build 26A5421a), Apple Silicon — note this is a prerelease OS, and beta builds have been actively changing TCC / Files & Folders behavior
- Terminal: standard macOS terminal session
- No Full Disk Access granted to Claude Code