Embedded claude-code CLI re-triggers macOS 'access data from other apps' TCC prompt every new session

Description

On macOS, the embedded claude-code CLI binary shipped inside Claude Desktop (identifier com.anthropic.claude-code, at a version-numbered path like ~/Library/Application Support/Claude/claude-code/<version>/claude.app/Contents/MacOS/claude) repeatedly triggers the macOS TCC dialog:

"claude.app" would like to access data from other apps. Keeping app data separate makes it easier to manage your privacy and security. [Don't Allow] [Allow]

This is the kTCCServiceSystemPolicyAppData permission (System Settings → Privacy & Security → App Management).

Steps to reproduce

1. Open Claude Desktop on macOS.
2. Start a new session/thread that spawns the embedded claude-code CLI.
3. Click Allow on the resulting TCC prompt.
4. Start another new session/thread.
5. The same TCC prompt reappears for a new process (different pid, same binary/identifier), instead of reusing the grant from step 3.

Expected behavior

Once the user grants kTCCServiceSystemPolicyAppData access for com.anthropic.claude-code, macOS should cache that grant per identifier and not re-prompt for subsequent process launches of the same signed binary.

Actual behavior

The prompt reappears roughly once per new session/thread — observed 3 separate prompts within an 8-minute window, each with a different pid but the same responsible_path/binary_path and identifier=com.anthropic.claude-code.

What we tried

• Toggling the App Management entry for claude.app on in System Settings → Privacy & Security → App Management — did not stop the recurrence.
• tccutil reset SystemPolicyAppData com.anthropic.claude-code followed by a fresh Allow — did not stop the recurrence either; it re-prompted again on the very next new session.
• Verified the binary's code signature is stable and valid (not the cause): codesign -dv --verbose=4 shows Authority=Developer ID Application: Anthropic PBC (Q6L2SF6YDW), notarized, ticket stapled, consistent Identifier=com.anthropic.claude-code across launches.

By contrast, a related-but-distinct identity, com.anthropic.claudefordesktop (the desktop app itself, acting as the "responsible" process when spawning the 1Password CLI op as a subprocess), did respond correctly to tccutil reset + one fresh Allow — that grant cached and stopped re-prompting. So the caching behavior is inconsistent between the two Claude-related identities involved here.

Environment

• Claude Desktop / embedded claude-code CLI version: 2.1.229
• macOS (Darwin 25.6.0)
• Diagnosed via log show --predicate 'process == "tccd"', observing repeated AUTHREQ_PROMPTING events for service=kTCCServiceSystemPolicyAppData, subject=com.anthropic.claude-code, each with a new pid.

Impact

Minor/annoyance — no functional breakage, just a recurring permission dialog interrupting the user once per new session.