[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

Status Open
Reported on v2.1.250
Maintainer reply None cached
Activity 0 comments · opened Aug 28, 2026

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:

  1. Opening the agents view is reaching into a TCC-protected location it presumably doesn't need (or isn't handling the denial gracefully).
  2. 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

  1. Install/run the native macOS CLI (~/.local/bin/claude), fresh install, no Full Disk Access granted.
  2. Start claude in any directory.
  3. Press the left arrow key to open the agents view.
  4. 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 the PATH entry 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

View original on GitHub ↗