Protect what matters – even after you're gone. Make a plan for your digital legacy today.
Forum Discussion
mondesign
1 month agoNew Contributor
1Password CLI Service Account Bug Report
1Password CLI Service Account Bug Report SUMMARY Service account tokens fail with "Signin credentials are not compatible with the provided user auth from server" error when called from exec/auto...
thecatfix
1 month agoDedicated Contributor
I hit a very similar “works interactive, fails in automation” wall with op in agent/exec contexts, and after a bunch of time spent fighting it we stopped trying to make service-account auth be our runtime dependency.
Pragmatic workaround:
1. Stop calling op at runtime for hot paths (webhooks, sync loops, retrain jobs).
2. Inject the key once, run the operation, and then rotate/delete.
Concretely, for automation jobs that need an API key:
• pass the key as an env var for that single run (or a root-owned systemd drop-in if we need unattended operation),
• run the job,
• then rotate the key later.
This avoids:
• op signin vs eval "$(op signin)" weirdness in non-interactive shells,
• device/UUID caching surprises (~/.config/op/config),
• rate limits / “secure mediation layer” turning into a failure injector mid-run.
Why I think your report is onto something:
The error string (“Signin credentials are not compatible with the provided user auth from server”) smells like the CLI is making a determination based on more than just OP_SERVICE_ACCOUNT_TOKEN—possibly device registration state, daemon state, or non-interactive/TTY detection. Your observation that ~/.config/op/config regenerates a device id that doesn’t match the token’s embedded device UUID is exactly the kind of mismatch that would explain a server-side reject in one context but not the other.
If you must keep using service accounts in automation, the “boring under pressure” version is:
• fetch secrets once (manually or via an interactive step),
• store them in a locked-down systemd environment override (root-owned, 0600, not in repo),
• avoid repeated op calls in tight loops (rate limit + flakiness),
• treat op as provisioning, not runtime dependency.
If 1Password wants this to be a supported pattern, IMO the CLI needs:
a documented, supported non-interactive service-account auth mode with no TTY assumptions.
• deterministic device identity behavior (no surprise device UUID conflicts),
• clear retry-after semantics when rate-limited.
Not sure if this is the Environments feature or the Server Connect.
Its really confusing trying to figure it out