Protect what matters – even after you're gone. Make a plan for your digital legacy today.
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/automated contexts, but work from interactive shell on the same system. ENVIRONMENT OS: Ubuntu 25.10 (Questing Quokka) Kernel: Linux 6.17.0-8-generic x86_64 1Password CLI Version: 2.32.1 Shell: bash Service Account: Multiple tested (both fresh and rotated tokens) Connect Server: Not running (confirmed via docker ps and process list) ISSUE DESCRIPTION Service account authentication fails consistently with this error: [ERROR] 2026/02/05 15:16:50 Signin credentials are not compatible with the provided user auth from server WHAT WORKS: Interactive shell (as root) - export OP_SERVICE_ACCOUNT_TOKEN='ops_eyJ...' then op vault list returns vault list successfully WHAT FAILS: Same token, same user, via wrapper script or exec - /usr/local/bin/op-sa.sh vault list gives ERROR: Signin credentials are not compatible Wrapper script (/usr/local/bin/op-sa.sh): #!/usr/bin/env bash unset OP_CONNECT_HOST unset OP_CONNECT_TOKEN unset OP_SESSION export OP_SERVICE_ACCOUNT_TOKEN='ops_eyJ...' exec /usr/bin/op "$@" DIAGNOSTIC STEPS TAKEN Environment comparison: Verified that OP_SERVICE_ACCOUNT_TOKEN is identical in both contexts. Interactive shell env shows correct token. Via wrapper bash -c 'env' shows identical token. Cleared all op state multiple times: killall -9 op and rm -rf ~/.config/op ~/.op /run/user/0/op-daemon.* Tested multiple service accounts: Original "Chris" account, rotated token for "Chris", and fresh "test" account. All fail with same error from wrapper/exec, all work from interactive shell. Verified no Connect Server: No Docker containers running, no OP_CONNECT_* environment variables set, pure service account + CLI setup. Token format verified: Single line (no newlines/wrapping), correct base64 encoding, no "illegal base64" errors. CONFIGURATION FILES CHECKED The file ~/.config/op/config gets recreated with device ID: {"latest_signin": "", "device": "bl6dyt5omziik2hw32myzslvje", "accounts": null} The device ID in config differs from the deviceUuid embedded in the service account token, which might be causing the conflict. EXPECTED BEHAVIOR Service account tokens should authenticate successfully regardless of whether they're called from an interactive shell or an automated/exec context, as long as the OP_SERVICE_ACCOUNT_TOKEN environment variable is set correctly. ACTUAL BEHAVIOR Authentication fails with "Signin credentials are not compatible" error when called from non-interactive contexts, despite identical environment variables. REPRODUCTION STEPS Create a service account in 1Password web UI. Copy the service account token. Create wrapper script with token hardcoded (see above). Run: ./wrapper.sh vault list and observe error. Run same token via manual export + op vault list in interactive shell and observe success. ADDITIONAL NOTES The error message suggests a server-side authentication rejection, not a client-side configuration issue. The fact that interactive shell works but exec fails suggests the op CLI binary is checking some process context beyond environment variables. Possible security feature that's incompatible with automation use cases? WORKAROUND ATTEMPTED None successful. Manual execution required for now. QUESTIONS Does the op CLI check process lineage or TTY status when validating service account tokens? Why does the config file cache a device ID that conflicts with service account deviceUuid? Is there a way to force service account authentication without any cached state interfering?Service Account Rate Limits: 15+ Minutes Block, No Backoff Duration Shown
Environment: - 1Password CLI (latest) - Service Account (not personal account) - Linux systemd service using LoadCredentialEncrypted - op inject to load 2 secrets at startup --- The Problem My systemd service uses a 1Password service account to inject 2 secrets at startup via op inject. While debugging an unrelated configuration issue, I restarted the service approximately 15 times over 10 minutes. This triggered a rate limit that has now persisted for over 15 minutes with no sign of clearing. The Error Message [ERROR] 2026/01/31 22:35:22 Too many requests. Your client has been rate-limited. Try again in seconds Note the blank where the number should be — there's no indication of how long to wait. Observed Behavior ┌──────────────────┬────────────────────────────────────┐ │ Operation │ Result │ ├──────────────────┼────────────────────────────────────┤ │ op whoami │ ✅ Works (authentication succeeds) │ ├──────────────────┼────────────────────────────────────┤ │ op vault list │ ❌ Rate limited │ ├──────────────────┼────────────────────────────────────┤ │ op inject │ ❌ Rate limited │ ├──────────────────┼────────────────────────────────────┤ │ op read op://... │ ❌ Rate limited │ └──────────────────┴────────────────────────────────────┘ This indicates the rate limit is applied per-operation-type — authentication endpoints work fine, but any vault/item access is blocked. Issues 1. Rate limit is extremely aggressive — ~15 requests over 10 minutes triggered a 15+ minute block. This is a typical debugging session, not abuse. 2. No backoff duration shown — The error says "Try again in seconds" but the actual number is missing. I have no idea if I should wait 1 minute or 1 hour. 3. No way to check status — There's no op rate-limit-status command or API to check current quota/reset time. 4. Service accounts should have higher limits — These are designed for automation and CI/CD where rapid retries during debugging are expected behavior. 5. Disproportionate impact — A brief debugging session can take down production services for an extended period with no recourse. Expected Behavior - Show the actual backoff duration in the error message - Faster reset — 1-2 minutes, not 15+ - Higher thresholds for service accounts — differentiate from potential abuse patterns - Rate limit status endpoint — let us query current quota and reset time - Graduated response — warn before hard blocking, or use exponential backoff instead of a cliff Workaround Wait and hope. There's no way to know when access will be restored. --- Request: Can someone from the 1Password team clarify the rate limit policy for service accounts and whether the blank duration in the error message is a known bug?
Link the 1Password CLI in a container to the 1Password application on the host
First, thanks to all the Team for making dev tools available to 1Password family subscribers. It allows solo developers like me to use integration solutions during development at a budget price. Regarding integration, I try to access secrets using the 1Password CLI from a Docker container. I'd like to find a solution to link the CLI tool (in the container) to the 1Password application (running on the host). I already solved similar situations by using bind mounts to share the communication socket between a client and its server. However, I am unable to locate the Unix socket used by the 1Password CLI and 1Password Application to communicate. Could you give me some guidelines? Are there other, more straightforward ways to link the 1Password CLI in a container to the 1Password application on the host? FWIW: I run the latest stable version of 1Password CLI and application Both the host and the containers are based on Debian Arch is amd64 I have a family subscription Using an OP_SERVICE_ACCOUNT_TOKEN stored in an environment variable is not a solution, as the visible service account token may leak into other unintended applications running in the dev container (e.g., VS Code). Regards, -- Sylvain
1password input focus lag with lots of inputs
I'm running into an issue where 1password seems to significantly slow down interaction with the webpage I'm working on. There's a ton of input fields of which most are hidden, I cannot lower the amount of inputs, in fact I have to increase the amount of inputs due to how the system works. Every time I click on an input, the focus is delayed by ~200ms or so. The next time I select the same input field it's instant. 1password seems to do something that slows down the focus event. I made a performance recording in firefox. I selected 3 inputs and after the 3rd on selected the same 3 in the same order with no slowdown. I've tried adding data-1p-ignore and autocomplete="off" but it didn't solve anything.
WSL2 + 1Password CLI
I have a WSL2 system set up with NixOS where I used to be able to use shell plugins (primarily the `gh` tool for GitHub) - but today it is not working, throwing an error message: [ERROR] 2025/12/27 22:35:25 Shell Plugins can only be used with the 1Password app integration enabled. To learn more about this feature, check out: https://developer.1password.com/docs/cli/about-biometric-unlock/ This used to work - but unfortunately I don't know exactly _when_ it stopped working, I use the VM sporadically. Config: $ op plugin inspect ? Choose which CLI configuration to inspect: gh (GitHub) GitHub CLI Configured Aliases ✔ Alias for "gh" configured ✔ Aliases sourced (/home/gac/.config/op/plugins.sh) Configured Credentials ✔ Configured as global default: CREDENTIAL TYPE ITEM VAULT GitHub Personal Access Token GitHub Personal Access Token Private Versions: $ uname -a Linux wsl 6.6.87.2-microsoft-standard-WSL2 #1 SMP PREEMPT_DYNAMIC Thu Jun 5 18:30:46 UTC 2025 x86_64 GNU/Linux $ nixos-version 25.11.20251226.f560cce (Xantusia) $ op --version 2.32.0 $ wsl.exe --version WSL version: 2.6.3.0 Kernel version: 6.6.87.2-1 WSLg version: 1.0.71 MSRDC version: 1.2.6353 Direct3D version: 1.611.1-81528511 DXCore version: 10.0.26100.1-240331-1435.ge-release Windows version: 10.0.26200.7462 If biometric login is a hard requirement then this is problematic to say the least as this is a desktop - there is no Windows Hello and no biometric capability. The documentation page does redirect to a different page about app integration, however this seems to only cover common use cases such as "I am using Windows and I want access to 1Password from Powershell" or "I have macOS and want access from the native terminal with `bash`/`zsh`". There doesn't seem to be any advice for running within a WSL2 virtual machine where 1Password is running _outside_ of the VM and I need access for shell plugins _inside_ the VM... Any tips or advice?
Unofficial 1Password SDK for Rust
For some small projects I wanted to use a secure way of handling secrets in my backend code, without taking out the big guns and adding a ton of infrastructure overhead (e.g: Azure Key Vault). After some "research" and diving into the op cli options and official Python, Javascript and Go SDKs, I thought I could probably build a simple wrapper around the core SDK library used in the Python SDK. After some trial implementations across multiple rust projects I thought it would be a nice addition to 1passwords ecosystem. If you're interested using the SDK head over to the github page at: https://github.com/Trendium-Labs/corteq-onepassword Curious about the security and inner workings? it's documented at https://github.com/Trendium-Labs/corteq-onepassword/blob/main/docs/ARCHITECTURE.md Please share your feedback, thoughts and use cases to improve this unofficial SDK. Ps:1P_Phil and team have been notified to see if and how to take this unofficial approach forward. Happy holidays! BrianMissing op-ssh-sign-wsl on Windows WSL
Hi team. I am trying to use the 1Password SSH Agent with WSL2, but I keep getting this error when SSH is invoked: fatal: cannot exec '/mnt/c/Users/bronze/AppData/Local/1Password/app/8/op-ssh-sign-wsl': No such file or directory error: fatal: failed to write commit object Environment: Windows 10 1Password desktop installed and signed in SSH Agent enabled in 1Password desktop WSL2 (Ubuntu) op installed via the official 1Password page op --version: 2.32.0 Issue: Running SSH inside WSL fails because the binary op-ssh-sign-wsl is missing. Running:ls ~/.1password/agent shows no op-ssh-sign-wsl. op ssh commands are recognized or partially recognized, but signing still fails due to missing binary. What I’ve tried: Reinstalled WSL on Windows. Disabled and Re-enabled SSH Agent on the Windows app Reinstalled 1password-cli inside WSL through the official page Restarted WSL and my machine. Same result: op-ssh-sign-wsl is not created. Thanks in advance.
