[Bug] macOS: sidecar code-signing identifier mismatch causes an unkillable TCC consent loop — Buzz never appears in Privacy & Security

[mattalldianhr]

Summary

On macOS, sidecar binaries in Contents/MacOS/ are code-signed with their own identifiers instead of the app's, and the bundle lacks com.apple.security.inherit. When a sidecar (e.g. buzz-acp) spawns a subprocess that triggers a TCC-gated access, macOS raises the consent prompt under the sidecar's identity. The user's "Allow" is recorded against xyz.block.buzz.app, so the next request — arriving under a different identity — prompts again.

The result is an unkillable consent loop: the dialog reappears indefinitely, and Buzz never appears in System Settings › Privacy & Security › Files and Folders, so there is no way to grant the permission persistently.

Evidence

Every sidecar has a distinct signing identifier:

$ for b in buzz-desktop buzz-acp buzz-agent buzz-dev-mcp buzz git-credential-nostr; do
    codesign -dv /Applications/Buzz.app/Contents/MacOS/$b 2>&1 | grep -oE "Identifier=[^ ]+"; done

buzz-desktop           Identifier=xyz.block.buzz.app
buzz-acp               Identifier=buzz-acp          ← mismatch
buzz-agent             Identifier=buzz-agent        ← mismatch
buzz-dev-mcp           Identifier=buzz-dev-mcp      ← mismatch
buzz                   Identifier=buzz              ← mismatch
git-credential-nostr   Identifier=git-credential-nostr ← mismatch

desktop/src-tauri/Entitlements.plist does not contain com.apple.security.inherit, so children do not adopt the app's TCC identity.

Reproduction

1. Configure a managed agent that shells out to a tool which reads another app's container. In my case the agent calls op (1Password CLI), which reads ~/Library/Group Containers/2BUA8C4S2C.com.1password.
2. Let the agent run.
3. macOS shows "Buzz would like to access data from other apps."
4. Click Allow (or Don't Allow) — the prompt returns on the next invocation, indefinitely.

Observed ~110 prompts in 58 seconds while an agent was active.

tccd attributes the request to the sidecar while naming Buzz as responsible:

Handling access request to kTCCServiceSystemPolicyAppData,
  from Sub:{xyz.block.buzz.app}
  Resp:{... responsible_path=/Applications/Buzz.app/Contents/MacOS/buzz-desktop,
        binary_path=/opt/homebrew/Caskroom/1password-cli/2.32.0/op},
  ReqResult(Auth Right: Unknown (Service Policy), promptType: 1, DB Action:None)

DB Action:None on every request — no decision is ever persisted.

Not a 1Password-specific bug

op is incidental. I verified by measuring TCC events per invocation that this is not fixable from the credential tool's side — all of these still produce 2 TCC events per call:

Attempt	op works	TCC events
Baseline	yes	2/call
OP_BIOMETRIC_UNLOCK_ENABLED=false	yes	2/call
Cleared system_auth_latest_signin in ~/.config/op/config	yes	2/call
OP_CONFIG_DIR pointed at a socket-free dir	yes	2/call
Removed ~/.config/op/op-daemon.sock	yes	2/call
All combined + explicit --account	yes	2/call

The same op invocation from a terminal also generates 2 TCC events per call but produces no prompts, because the terminal has a persisted grant. The access is normal; the missing grant is the bug.

Any agent shelling out to any tool that touches another app's data will hit this — op is just the first example.

Suggested fix

Add com.apple.security.inherit to desktop/src-tauri/Entitlements.plist so sidecars inherit the app's sandbox/TCC identity:

<key>com.apple.security.inherit</key>
<true/>

Signing the sidecars with the app's identifier (rather than per-binary identifiers) in the release pipeline would also address it, and may be the more robust fix since inherit is primarily a sandbox-inheritance mechanism. Someone closer to the block/apple-codesign-action setup should confirm which is correct here — I've only verified the diagnosis, not the fix.

Environment

• Buzz Desktop 0.4.24 (Block-signed, TeamIdentifier=EYF346PHUG, notarized, codesign --verify --deep --strict passes)
• macOS 26.5.2 (Apple Silicon)
• 1Password CLI 2.32.0 (TeamIdentifier=2BUA8C4S2C)

Impact

Any macOS user running managed agents that invoke external tools touching other apps' data. The app is unusable while an agent runs — the dialog steals focus repeatedly and cannot be permanently dismissed, because no grant can ever attach to the app.