Protect what matters – even after you're gone. Make a plan for your digital legacy today.
Feature Request: Show Original Contributor of Items in Shared Family Vaults
Summary Please add a built-in way to display who originally created or contributed an item to a shared vault in 1Password Family. Problem In shared family vaults, it is currently not possible to see who an item originally belongs to once it has been shared. This makes it unclear who owns a specific account, even though the item is visible to everyone in the family. As a workaround, we manually add tags with the name of the person who created or contributed the item. This allows sorting and filtering by owner, but it is manual, error-prone, and easy to forget. Proposed Feature Display non-editable metadata such as: “Contributed by: Name” or “Original owner: Name” This information should remain visible in the item details after sharing or moving an item into a shared family vault. Benefit This makes it easy to understand who an account actually belongs to, even when it is shared for convenience. It improves clarity in family vaults, avoids confusion, and removes the need for manual tagging. Reference Apple Passwords already shows this information for shared items using labels like “Contributed by: Name”, which provides clear ownership at a glance.
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, -- SylvainJanuary 2026 at 1Password: Taking on credential sprawl and advanced phishing scams
We kicked off 2026 with a big step forward for access governance with 1Password Unified Access, rolled out stronger phishing protection, and shipped a steady stream of fixes and improvements across every platform. In case you missed it Governing access beyond SSO with 1Password Unified Access In January, we announced the public preview of 1Password Unified Access, a new capability that helps organizations discover and govern company-owned credentials — including shared and non-SSO accounts that often fall outside traditional identity systems. Unified Access combines 1Password Enterprise Password Manager and 1Password SaaS Manager to give admins a clearer view of which apps rely on traditional credentials, who has access, and when that access should be rotated or revoked. When someone changes roles or leaves, you can revoke access and rotate credentials with a single action. For employees, the App Launcher brings both SSO and non-SSO apps into one place, making it easier to get work done without hunting for logins scattered across portals and vaults. The public preview is available to 1Password EPM Business customers in US-hosted environments with at least 100 users. 👉 Read the announcement and learn how to join the public preview. Introducing extra protection against phishing attempts 1Password has always protected you by refusing to autofill credentials on mismatched sites. But we know that sometimes you might not realize why autofill didn't work—so you'd manually copy and paste instead, which could still get you phished. Now, we've added an extra layer of protection. When you try to paste a password into a site that doesn't match the URL saved in 1Password, you'll see a warning pop-up in your browser—a gentle nudge to slow down and double-check the URL before you continue. Phishing attacks are everywhere right now, and thanks to AI, they're harder to spot than ever. Those fake login pages look almost perfect, and it only takes one quick moment to accidentally hand over your credentials to a scammer. This feature is rolling out to all Individual, Family, and Business customers over the next few weeks. For Individual and Family users, built-in phishing protection will be enabled by default. If you're a 1Password Admin, you can enable it for your team in Authentication Policies in the admin console. 👉 Learn more about phishing protection. Random but Memorable We kicked off the new year with an episode focused on cybersecurity resolutions that are actually worth sticking to! This episode turns advice from last season's guests into a practical checklist, covering small, ten-minute wins like freezing your credit, using passkeys, turning on MFA, cleaning up your digital junk drawer, and adopting a "politely paranoid" mindset to spot scams before they do damage. "If your heart rate increases, your caution should too. If a situation is urgent, contact the sender through a trusted channel, NOT the website, email, or phone number you see in the message." – Dave Lewis, Global Advisory CISO 👉 Listen to the episode Release note highlights 1Password in the Browser When setting up the 1Password extension in Firefox, you now see the permissions page first. We've improved localization for a number of our supported languages. We've fixed an issue where a scrollbar could appear unexpectedly on webpages. We've fixed an issue where the 1Password extension could break syntax highlighting for code blocks on some websites. Mac, Windows, and Linux We've fixed an issue where you couldn't interact with the prompt to turn on two-factor authentication when signing in to the app. We've improved localization for a number of our supported languages. We've fixed an issue where one-time password fields from Bitwarden login items didn't import correctly. We've updated the account icon shown in the authentication prompt when using the CLI or SDK desktop app integrations to have rounded corners. We've fixed an issue where the step to download the 1Password extension was missing from Guided Setup for individual and family accounts. We've fixed an issue where selecting the Create vault button multiple times could cause multiple vaults to be created. We've fixed an issue where items containing files could be duplicated or moved into accounts where file storage was turned off. [Mac only]: We've added Dark Mode and clear 1Password icons for macOS Tahoe. [Windows only]: You now only see the Windows Passkeys setup prompt if an unlocked account has the setting "Passkey item support" enabled. [Windows only]: We've added settings to reduce lag and choppy performance on some high refresh rate G-SYNC monitors. [Windows only]: We've fixed intermittent connection issues between the MSIX version of 1Password for Windows and the browser extension. [Windows only]: We've fixed an issue where op-ssh-sign-wsl.exe could fail to translate Windows Subsystem for Linux (WSL) paths to Windows paths, causing Git commit signing to fail in WSL. [Windows only]: We've fixed an issue that prevented ADMX templates from being ingested and applied in Microsoft Intune. [Linux only]: We've improved error messages and made restarting device enrollment smoother when it fails. [Linux only]: The Linux import callouts now point to the correct support article. [Linux only]: Pressing the Alt key now focuses the 1Password menu icon instead of showing the legacy menu bar. iOS and Android We've made improvements to item import and export functionality. We've improved localization for a number of our supported languages. We've fixed an issue where one-time password fields from Bitwarden login items didn't import correctly. We've fixed an issue where the step to download the 1Password extension was missing from Guided Setup for individual and family accounts. We've fixed an issue where items containing files could be duplicated or moved into accounts where file storage was turned off. [iOS only]: We've fixed an issue where search would dismiss when a recent search was selected on iPadOS 26. [iOS only]: We've fixed an issue in Guided Setup where the Autofill step couldn't be marked as complete. [iOS only]: We've fixed a visual issue with the item list menu on iOS 18. [iOS only]: We've fixed an issue where the "Pull down to search instantly" search tip was dismissed too quickly on first sign in. [iOS only]: We've fixed an issue where the search field didn't work when linking a related item, and the full list of items was shown regardless of your search. [Android only]: We've improved the password autofill experience and added passkey support for Vanadium on GrapheneOS. [Android only]: We've fixed an issue where the bottom navigation didn't restore the last selected tab after restarting the app. [Android only]: We've improved autofill in Android apps where username fields were hard to fill or didn't show suggestions.
