Protect what matters – even after you're gone. Make a plan for your digital legacy today.
Prompted every time I need to sign a git commit or tag
I have 1Password set up to sign git commits and tags in both Windows and WSL (I use the latter most for development). Starting a few months ago but getting increasingly frustrating (especially when I rebase a lot of commits), I'm prompted every time I need to sign. My ~/.gitconfig is set up like so (relevant settings shown): [user] signingkey = ssh-ed25519 PUBKEY [core] sshCommand = ssh.exe [gpg] format = ssh [gpg "ssh"] program = "/mnt/c/Users/USERNAME/AppData/Local/Microsoft/WindowsApps/op-ssh-sign-wsl.exe" [commit] gpgsign = true [tag] gpgsign = true `ssh-add -L` (both the ELF executable in WSL as well as running the PE/COFF `ssh-add.exe`) shows my ssh auth and signing keys. 1Password - the desktop app - is also configured to only prompt when 1Password is locked or after 4 minutes. I get this same prompt-on-every-use behavior whether 1Password is open and unlocked or not. Works as expected for my browser extension, though. I found a post from about a year ago that someone resolved a similar behavior by re-installing 1Password. I may try that, but would rather hear from a dev to troubleshoot the issue in its current state so a proper fix could be made so this doesn't keep happening after winrot or whatever is causing this happens again to anyone.
SSH config managed from 1Password - alternative to SSH Bookmarks
(Mods: feel free to remove this if it's not appropriate here) I gave SSH Bookmarks a try but found it didn't quite cover my needs. No password/OTP auth, no way to use arbitrary SSH directives, no per-machine filtering, ... So I ended up building a small OSS tool called ssh-concierge that takes a similar approach but goes a bit further: it treats 1Password as the single source of truth for your entire SSH config, not just key-to-host mapping. In case it's useful to anyone else: https://github.com/bedezign/ssh-concierge Happy to answer questions!
Firefox extension autofill broken — InputJsonDeserializationFailed
Since updating to 1Password 8.12.5 on Linux, the autofill feature no longer works in Firefox-based browsers (Firefox and Zen Browser). The same extension version (8.12.4.46) works correctly in Chromium. Copying passwords from the extension popup works fine — only the fill/autofill operation is broken. Environment: OS: Arch Linux (kernel 6.19.6) 1Password app: 8.12.5 (also tested with beta 8.12.6-35 — same issue) 1Password extension: 8.12.4.46 (latest on AMO) Firefox: 148.0 (also tested with 147.0.4 — same issue) Chromium: autofill works with the same extension version and app Steps to reproduce: Open any login page in Firefox Focus on a username/password input field The 1Password inline menu appears and shows matching logins — this works Click on a login to fill — nothing happens Filling via the toolbar popup and keyboard shortcut also does nothing. Copying a password works fine. Error from about:debugging → 1Password → Inspect: Uncaught (in promise) Error: ⛔ Core error code: InputJsonDeserializationFailed sendCoreMessage background.js:108 nextFill background.js:108 What I've tested: Test Result Chromium + same extension + same app Fill works Firefox 148 / 147.0.4 InputJsonDeserializationFailed 1Password beta 8.12.6-35 InputJsonDeserializationFailed X11 instead of Wayland InputJsonDeserializationFailed Copy password from extension Works The Firefox extension's fill request (nextFill → sendCoreMessage) is rejected by BrowserSupport with InputJsonDeserializationFailed. The same extension version works in Chromium, so the issue is in the Firefox-specific fill payload. This is a regression from the 8.12.2 → 8.12.5 app update (downgrading is blocked by database migration).
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.
Using a Service Account token to grant a connect server acces to a vault
Hey. I'm using a service account token in a GitLab CI/CD pipeline, where I first install the 1Password CLI. It works great when i create a vault and give permissions to some groups on that vault. I would like to use the command "op connect vault grant" to give our Connect Server access to that newly created vault, so that I can subsequently use our Connect Server and do operations on that newly created vault. However I am encountering the following error: $ op connect vault grant --server OUR-SERVER --vault "VAULT_NAME" [ERROR] 2026/02/18 16:35:30 There are 0 servers that match {"OUR-SERVER"}. Try again and specify the servers's UUID instead. This is a bit weird since I can type in that command locally, using 1password CLI, and it works great. I suspect that Service Account tokens cannot grant vault permissions to Connect servers, but i'd like to be sure. If it is the case, what alternative could be used to obtain the same behaviour ? The goal here is obviously to not have to do anything manually, and it is still secure since all our credentials and secrets are stored in Gitlab CI/CD variables. Thanks Edit: I also tried with the server ID instead of its name, but same result. Edit2: It is not possible, there is an "Unsupported commands" small blue paragraph in this documentation that I missed: https://developer.1password.com/docs/service-accounts/use-with-1password-cli/#supported-commandsIntroducing: Desktop auth for SDKs & 1Password Environments access for CLI, SDK & Service accounts
Today, we're introducing two new features to help developers get secrets to the right place at the right time, without sprinkling them across files, repos, and build logs. Programmatically read 1Password Environments (read‑only, now in beta) If you store project environment variables in 1Password Environments, you can now read them at runtime via the 1Password CLI and SDKs. That means tools can pull secrets when they’re needed, instead of maintaining .env files or managing long‑lived secret syncs. A few places this shines: CI/CD workflows: Retrieve and inject .env variables during builds using a service account. Containers/Kubernetes: Apps read connection strings at startup. Local + AI-assisted tooling: Scripts/Make targets fetch tokens on demand while keeping secrets out of the model context. Video not displaying? Watch it here. Desktop authentication for 1Password SDKs Fresh out of beta, SDK integrations can now authenticate through the 1Password desktop app with a biometric/password prompt. Sessions inherit the signed‑in user’s access and time out after 10 minutes of inactivity (or when 1Password locks). This unlocks higher‑impact workflows, including full vault management (create/read/update/delete/list), managing vault permissions, and batch item operations for teams operating at scale. Video not displaying? Watch it here. Check out the details For the full details, read the launch post. Questions, edge cases, or wish‑list items? Drop them below – we’re listening.
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?
