Protect what matters – even after you're gone. Make a plan for your digital legacy today.
SSH Agent Forwarding to Remote Mac
Okay! I have a Mac Mini that I use as a home server (it was effectively free after trade ins of old stuff). I do have 1Password and its SSH agent running there for when i'm using it with a screen attached, but I'd like to be able to initiate 1Password requests when SSH'ed into the box as well so i can perform `git` operations in particular. I have tried https://developer.1password.com/docs/ssh/agent/forwarding/#remote-workstation and to an extent it works. ssh -A my_name@macmini.local cat ~/.ssh/config # Output, showing we are trying to force using SSH_AUTH_SOCK # Match host * exec "test -z $SSH_TTY" # IdentityAgent "~/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock" echo $SSH_AUTH_SOCK # /Users/my_name/.ssh/agent/s.czyqavwOqO.sshd.RviXimjiEr So I can see that I'm getting some kind of agent socket attached appropriately. I've configured the `.ssh/config` to not use the IdentityAgent when over SSH (it's not commented out in the actual file, just commented here for display purposes in the code block). However, when trying to run a git command, it's like SSH doesn't even try to use the auth socket for pulling data and `ssh-add -l` is equally unhelpful. ssh-add -l # The agent has no identities. git pull # git@github.com: Permission denied (publickey). # fatal: Could not read from remote repository. # Please make sure you have the correct access rights # and the repository exists. I am sure I'm just missing a configuration of some kind somewhere but I am at a loss for what it could be. Happy to provide other debug information from either the host or the remote Mac mini as needed.[BUG REPORT] Two issues when editing multiple password fields
There are two issues with when editing multiple password fields of an item in 1Password. 1Password for Mac 8.12.2 81202037, on PRODUCTION channel Issue 1 When filling in multiple password fields below each other, I copy-past values from another application. When coming back to 1Password, the focus between password field items start to flicker. This is hard to stop and very annoying. You see this issue occur at 45 seconds into YouTube video 1Password UI Issues. Issue 2 Every time the password field gets focus, a "Generate a New Password" popup is shown below. This popup block direct access to the item below. This is very annoying. In YouTube video 1Password UI Issues, you see multiple password fields below each other in a single section. When I click on the input field of "Item 3" and paste a password value in the field, I want to be able to directly click on input field of "Item 4", which I cannot do because the annoying "Generate a New Password" popup is blocking direct access to this. I absolutely do NOT like these type of popups. They are frustrating and distracting. I have not asked for this "feature" and I want an option to disable this. I much more prefer a dedicated button in 1Password to generate a password. That way, I can choose myself when I actually want to generate a password in the password field that I have in focus. Don't annoy users with feature you think they like. Give users an option to disable/hide these unwanted UI features.1Password Connect Doesn't Appear to Sync Permissions
After submitting 1Password Connect Token Permissions Don't Appear to be Granular | 1Password Community , I update the permissions for the Access token for my dev environment. I then waited, and restarted the onepassword-connect deployment in my Kubernetes instance, which synced (verified in the 1PW UI under "Sync activity"). I did this twice. Despite the token having read/write access to the vault now, and being synced multiple times, when I apply terraform in that environment, and the onepassword terraform provider attempts to create a new entry, I see: Error creating 1Password item, got error failed to create item using connect: status 403: Authorization: token does not have permission to perform create on vault [redacted] Is there an additional action required to allow these permissions to sync?1Password Connect Token Permissions Don't Appear to be Granular
I have a 1PW token that Terraform uses. Up until now, I only wanted Terraform to be able to read from this vault. But now I have a use case for using some items in Terraform to create a 1PW entry. However, I don't seem to be able to assign only the "create" and "edit" permissions without also granting the archive & delete permissions, which I don't want Terraform to be capable of (accidentally) doing. Reproduction Steps Open 1PW connect entry Go to access token with read only permission Attempt to grant that access token additional "create" and "edit" permissions. Expected Behavior Check off the Create and Edit items, and have those permissions take effect. Actual Behavior Checking create or edit also appears to check off "Archive" and "Delete" Screen capture below demonstrating the behavior
1Password Environments issue with VSCode and Claude Code Extension
I've noticed a curious issue in testing 1Password Environments in a repository where I'm editing with VSCode and using the Claude Code extension in VSCode. Since enabling 1P Environments, I've noticed that the Source Control sidebar gets stuck refreshing Git Status, and Claude Code slows or stalls. Running Claude Code outside of VSCode works fine (as does using Git in Terminal, and so I wonder if this is a VSCode issue? I have the VSCode 1Password extension, as well as the Claude Code for VSCode extension, among others. Happy to provide other details if you can let me know what would help.
Disabling interactive prompt to set up account in op CLI?
I have a developer environment setup script that tries to get some optional secrets from the 1Password CLI. Some developers aren't signed in, or don't want to expose their 1Password on the CLI; I don't want to force it on them. On a machine where the CLI has been installed, but has not been set up with an account, a command like this: somevar=$(op item get --vault "test vault" "test item" --fields credential --reveal) ... gets stuck on this interactive prompt: No accounts configured for use with 1Password CLI. You can either: - Turn on the 1Password desktop app integration to sign in with the accounts you've added to the app: https://developer.1password.com/docs/cli/app-integration/ for details. - Add an account manually with 'op account add' and sign in by entering your password on the command line. See 'op account add --help' for details. - Authenticate using a 1Password service account by setting the 'OP_SERVICE_ACCOUNT_TOKEN' environment variable to your service account token. Learn more: https://developer.1password.com/docs/service-accounts/ - Use 1Password CLI with a Connect server by setting the 'OP_CONNECT_HOST' and 'OP_CONNECT_TOKEN' environment variables to your Connect host and token, respectively. Learn more: https://developer.1password.com/docs/connect/ Do you want to add an account manually now? [Y/n] That blocks the script. How can I disable that, so the op command just exits with a failure code if it hasn't been set up? I tried `</dev/null` and `2</dev/null`, no dice. Secondly, how can I reliably check if the CLI is logged in, either via `eval $(op signin)` or the desktop integration? `op whoami` works with `eval $(op signin)`, but not with the desktop integration: it reports `account is not signed in` The best I could find was `op vault list`, which exits with code 0 if the user is logged in either way, but it seems a bit wasteful. Thanks!
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?
