No Accounts Configured for Use With 1Password CLI — Fix

When op stops with no accounts configured for use with 1Password CLI, the binary is installed and working. It simply cannot see any 1Password account it is permitted to use.

$ op item list
[ERROR] 2026/08/12 09:14:22 no accounts configured for use with 1Password CLI

1Password's own guidance points at three routes out, and which one is right depends entirely on where the command is running:

Why This Happens

The CLI does not hold your credentials itself. It obtains authorisation from one of three sources, and this error means all three came up empty:

1. The 1Password desktop app, when CLI integration is enabled — the app unlocks, and the CLI rides along with it.
2. An account added directly to the CLI with op account add, which stores the account details locally and authenticates with your account password and Secret Key.
3. A service account token in the OP_SERVICE_ACCOUNT_TOKEN environment variable, used for unattended automation.

A fresh install has none of these, which is why the error appears immediately after brew install 1password-cli or an equivalent. It is a configuration state, not a fault, and your vault data is entirely unaffected — the desktop app and browser extension keep working normally throughout.

Fix 1: Turn On Desktop App Integration (Workstations)

This is the intended path on a machine where you already use 1Password, and it is the most secure of the three because no credential is written to disk.

1. Open the 1Password desktop app.
2. Go to Settings → Developer.
3. Turn on Integrate with 1Password CLI.
4. Open a new terminal window.

That last step is not optional. The integration is picked up when a shell starts, so any terminal opened beforehand keeps the old environment and continues to fail. The same applies to editors and IDEs — quit and relaunch them completely rather than opening a new tab.

Confirm it took effect:

op account list
op whoami

If the checkbox is not enabled, attempts to link an account can fail silently, which is exactly what produces this error on a machine where 1Password is otherwise working fine.

Fix 2: Add an Account Directly (Servers and Headless Machines)

Where there is no desktop app, add the account to the CLI itself:

op account add --address my.1password.com --email you@example.com

You will be prompted for your Secret Key and account password. Use your own sign-in address if your organisation is on a different domain, such as my.1password.eu or a custom business domain.

Then sign in:

eval $(op signin)

Session tokens expire after 30 minutes of inactivity, so long-lived shells will need to re-authenticate periodically. That is a deliberate safety property, not something to engineer around.

Fix 3: Use a Service Account (CI and Automation)

Interactive sign-in has no place in a pipeline. Create a service account in your 1Password account, grant it access to only the vaults the job actually needs, and store its token in your CI platform's secret store:

export OP_SERVICE_ACCOUNT_TOKEN="ops_..."
op item list --vault "Deploy Secrets"

The CLI detects the variable automatically — no op signin step is required. Scope matters here: a service account with access to every vault turns one leaked CI token into a full compromise, while one scoped to a single vault limits the blast radius to secrets that job already handles.

What Not To Do

• Do not write your Secret Key or account password into a file, a script, or an environment variable. The Secret Key exists precisely so that a stolen password is not enough to reach your data; storing it alongside the password removes that protection entirely.
• Do not export items to a plaintext file to work around the error. That converts an encrypted vault into an unencrypted one and usually leaves the file behind indefinitely.
• Do not share one service account token across every pipeline. Separate tokens with separate vault scopes mean a compromise in one project does not reach the others.

Every legitimate fix above authenticates the CLI properly rather than moving secrets somewhere less protected.

Verify the Fix

op whoami
op account list
op vault list

op whoami returning your account URL and user confirms authentication succeeded. op vault list returning the vaults you expect confirms the identity has the access you intended — worth checking separately for a service account, where sign-in success and sufficient vault scope are different things.

Prevent It From Recurring

• Standardise per environment: desktop integration for people, service accounts for machines. Mixing them is what produces surprise failures in CI.
• Document the sign-in address for your organisation in your onboarding notes — a wrong --address is a common follow-on error.
• Scope service accounts to single vaults and rotate their tokens on a schedule, in line with your shared vault structure.
• Add op whoami to the top of scripts that depend on the CLI, so an unauthenticated run fails immediately with a clear message.
• Cover the CLI in onboarding alongside the app, so new team members enable integration on day one — see our team onboarding guide.