op CLI desktop-app integration fails under macOS TCC Group Container protection

Question

Environment: macOS (Sequoia/Tahoe), 1Password 8 desktop + CLI 2.35. Integration enabled (Settings → Developer → Integrate with CLI; system-auth unlock on).

Symptom: op reports "No accounts configured." op --debug shows the real cause:
Skipped loading desktop app settings file. The desktop app might not be installed:
open ~/Library/Group Containers/2BUA8C4S2C.com.1password/.../settings/settings.json: operation not permitted

Root cause: op's desktop-app discovery reads settings.json inside 1Password's Group Container. On modern macOS, a process reading another app's Group Container requires Full Disk Access — there's no per-file or per-container TCC grant.

Why the usual workaround is self-defeating: the common "fix" is to add the terminal (Terminal/iTerm) to Full Disk Access. But FDA is machine-wide — it grants that terminal, and every process it ever spawns, read access to all protected app data (Messages, Mail, Safari history, every app's container), not just 1Password's. So to unlock a narrow, biometric-gated secret channel, you're forced to open blanket access to the entire machine's data — a far larger exposure than the credential handling the integration is meant to make safer. It negates the security rationale for using the CLI integration at all, and it's a non-starter on any security-conscious setup.

Note: the actual comms are XPC (op-cli/desktopapp/ipc/xpc), which is not filesystem-TCC-gated — only the file-based discovery is blocked.

Requested fix: move integration discovery to XPC (query a well-known Mach service for "enabled? accounts? policy?") instead of reading a file in the protected container — or write the discovery manifest outside the Group Container. Either removes the FDA requirement entirely, keeping credential access properly scoped instead of forcing a machine-wide grant.

Tjalling Ran · Answer

I ran into this issue as well. Agreed with the usual workaround introducing (way) too much exposure.

There’s another workaround: instead of reading the settings.json to enable the integration, the `op` CLI also enables it when it sees an environment variable OP_BIOMETRIC_UNLOCK_ENABLED with value `true`. It doesn’t seem to need any other config from the json file, so exporting that variable will do the trick. For example, in `~/.zshenv` (create the file if it does not exist yet):

# 1password cli: enable integration with the desktop app
# This works around the TCC-blocked settings.json read
export OP_BIOMETRIC_UNLOCK_ENABLED=true

The issue should still be fixed by 1password in a more user-friendly way i.m.o., but this approach worked for me.

Sign up

1Password employees: Sign in with SSO

Login to the community

1Password employees: Sign in with SSO