1Password CLI Service Account Bug Report

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