op CLI triggers macOS "access data from other apps" prompt on every run in daemon contexts — root cause: unconditional policies.json probe, even with a service account token
Summary: op performs an lstat on ~/Library/Group Containers/2BUA8C4S2C.com.1password/Library/Application Support/1Password/Data/settings/policies.json at startup, apparently checking for enforced enterprise policies. On macOS, App Data Protection treats any access into another app's group container as "op would like to access data from other apps" and prompts. For processes with no application ancestor (launchd jobs, daemon-spawned agents), the grant cannot be persisted, so the prompt appears on EVERY invocation. The probe happens even when OP_SERVICE_ACCOUNT_TOKEN is set and OP_BIOMETRIC_UNLOCK_ENABLED=false — i.e. when the desktop app is irrelevant to the invocation.
Environment: op 2.39.0 (Homebrew cask), macOS 26.5.1 (25F80), Apple Silicon, desktop app installed, Individual plan.
Steps to reproduce:
1. Create a service account and export its token.
2. Run "op vault list" from a context with no app ancestor — e.g. a one-shot LaunchAgent with ProgramArguments [/opt/homebrew/bin/op, vault, list] and OP_SERVICE_ACCOUNT_TOKEN (plus OP_BIOMETRIC_UNLOCK_ENABLED=false, to rule out app integration) in EnvironmentVariables.
3. Observe the TCC dialog. Re-run: it appears again, every time — there is no app identity for macOS to record the Allow against.
Expected: with a service account token in the environment (and/or app integration disabled), op should not touch the desktop app's group container at all — or should treat a TCC denial of the policies probe as silently equivalent to file-not-found.
Actual: the probe runs unconditionally. OP_DEBUG=true shows it:
WARN | no enforced policies found error="reading policies file: lstat /Users/<user>/Library/Group Containers/2BUA8C4S2C.com.1password/Library/Application Support/1Password/Data/settings/policies.json: no such file or directory"
Notably, op already handles the failure gracefully — the command succeeds via the token regardless of whether the dialog is answered Allow, Don't Allow, or ignored. The prompt is purely cosmetic, which makes it pure prompt fatigue: an hourly scheduled job produces an hourly dialog, forever, teaching users to click through security prompts.
Tested non-workarounds: OP_BIOMETRIC_UNLOCK_ENABLED=false (probe still runs); OP_CACHE=false (probe still runs).
Working workaround: granting the op binary Full Disk Access silences it — but that is a much broader grant than a secrets CLI should need, and it pins to the versioned cask path, so it must be re-granted after every CLI upgrade.
Suggested fix: skip the enforced-policies probe when OP_SERVICE_ACCOUNT_TOKEN is present or app integration is disabled; failing that, treat EPERM/TCC denial on that path exactly like ENOENT (the code already proceeds correctly in that case).
Related reports of the symptom (none identify this cause): https://www.1password.community/1password-at-home-31/1password-cli-op-command-causes-would-like-to-access-data-from-other-apps-warning-24173 and https://github.com/1Password/shell-plugins/issues/586 (blames op completion zsh — one trigger context, not the cause) and https://github.com/openclaw/openclaw/issues/55459 (blames the cache daemon; its --cache=false workaround does not stop the dialog).