Level up your business security with free, on-demand training and certification. Explore 1Password Academy today →
1Password Passkeys not usable in Chromium-based browsers
I’m running into an issue with 1Password Browser Extension and passkeys on Linux and MacOs. Its just not useable anymore. The option “Save and sign in with passkeys” is greyed out. 1Password never appears in passkey login flows. I have the issue on MacOS and Linux with Vivaldi and Chrome. Different machines and different browser but chrome based. With Firefox it works. What I’ve already tried Reinstalling the extension Reconnecting the desktop app Used nigthly builds Installed older chrome versions No change. Can someone help please. Thanks!
1password crazy high cpu usage on blank Chrome page.
Hello! Recently I have noticed my macbook air has been running crazy hot when Chrome was open. The battery was going blank craz fast. After taking a look at chrome task manager i noticed that one of my extensions is using crazy cpu power. 1 empty chrome tab open nothing else. I started uninstalling my addons and after uninstalling 1password my cpu usage plumeted to almost none. Has anyone else noticed this behaviour? I have removed the addon now and my temps are back to normal.
Chrome Extension - Blank
A quick one ... Running Chrome 147.0.7727.56 (Official Build) and this is what happened after the upgrade to this Chrome version. The Chrome extension no longer show anything and removing and re downloading the extension has not resolved the issue. Firefox and Safari (the later which I dislike as a browser and don't use at all) works. Thanksop item get --format json returns CONCEALED field values without --reveal flag
Hi, We are using the 1Password CLI heavily in scripted and AI-agent workflows where command output is captured into logs. Today we discovered a behavior in op item get that surprised us, and we'd like to confirm whether it is intentional or a candidate for change. What we observed We ran the same item retrieval six different ways against a CONCEALED field on a test API Credential item we created specifically for this verification: | # | Command | Returned the secret value? | |---|---|---| | 1 | op read "op://<vault>/<test-item>/credential" | YES (as designed) | | 2 | op item get "<test-item>"` (default text format, no --reveal) | NO — output: credential: [use op item get ID --reveal to reveal]` | | 3 | op item get "<test-item>" --format json (no --reveal) | YES — JSON output included "value": "<plaintext>" for the CONCEALED field | | 4 | op item get "<test-item>" --fields credential (no --reveal) | NO — output: [use op item get ID --reveal to reveal] | | 5 | op item get "<test-item>" --fields credential --reveal | YES (as expected — --reveal was passed) | | 6 | op item get "<test-item>" --reveal | YES (as expected --reveal was passed) | The surprise is #3: --format json silently returned the plaintext value even though no --reveal flag was passed. The text format (#2 and #4) clearly conceals the value with the message [use op item get ID --reveal to reveal], which strongly implies that --reveal is required to see the value. JSON output behaves differently. Why this matters to us Many agent and scripting workflows use --format json for parseability. A developer or AI agent might reasonably: Read the documentation, see that --reveal is needed to expose secrets Write op item get <id> --format json expecting metadata only Pipe the output to a JSON parser Inadvertently leak the secret value into logs, conversation context, or downstream tools We discovered this in the context of investigating a credential-exposure incident where an AI agent was capturing tool output into conversation logs. We ran the test against a throwaway test credential to verify the behavior before drawing any conclusions. The text-format default was safe; the JSON format was not. Our questions Is --format json returning plaintext for CONCEALED fields without --reveal an intentional design choice? If yes, what is the rationale? The asymmetry between text and JSON output is what surprised us. If intentional, would you consider documenting it more prominently? The current op item get documentation does not (as far as we can tell) warn that JSON format bypasses the --reveal requirement that the text format implies. If unintentional, would you consider concealing values in JSON output too (e.g., omitting the value field for CONCEALED fields, or replacing it with a sentinel like `"value": "<concealed>") unless --reveal is explicitly passed? Secondary feedback (lower priority) op read always returns the value to stdout. This is documented and we understand it is the command's purpose. But for AI-agent contexts, it would be useful to have a --check or --exists mode that verifies a path resolves without fetching the value. (Workaround: `op item get` with the vault/item portion of the path resolves the existence question without exposing the value, as long as we don't use --format json — see issue above.) op item list` is correctly metadata-only. We tested this exhaustively and confirmed it does not return values. However, the metadata it returns (item names, IDs, vault names, edit timestamps) is sensitive reconnaissance data in agent contexts. Could you consider adding a --minimal or --counts-only mode that returns just count: N for the matched query without surfacing item names? This would let workflows verify that a credential exists in a given vault without enumerating the inventory. op run masking is excellent and we love it. The automatic <concealed by 1Password> replacement on stdout/stderr from wrapped subprocesses is the gold standard. We've made op run the canonical pattern for any subprocess that needs credentials in our workspace. The --no-masking flag is correctly an opt-in rather than the default. Thank you for the careful design here. What we are doing in the meantime We have updated our workspace policy and AI-agent rule files to: Treat op item get --format json as a value-leaking command, on par with --reveal Use op run --env-file=<file> as the default credential injection pattern Use op read --out-file <path> whenever a credential needs to land on disk, never piping op read to stdout Never use op item list or any enumeration command in tool-output-capturing contexts We would still very much like your guidance on item #3 specifically, JSON format silently returning concealed values is the behavior that most worries us, because it is the easiest one to get wrong by accident. Thanks
Adding New Client's Account to Current Account?
Hello, I have 1Password where I have a Personal account and a Business account. My new client wants me to join her account. When I click the "accept invite" button, it doesn't give me a choice to sign in - only to register. Is there a way that I can add the client's 1Password account to my current 1Password? That way I won't have to sign in and out again. I'm on a MAC. Thank you!Unwanted switches after copy password
I frequently use the possibility to search and copy a password through my keyboard using the shortcuts (macOS 26.3). This works fine, however often I run into the problem after copying the password it switches to another space (I use multiple spaces on my Mac). So I’m not returning to the space/application I was coming from but am directed to another space where in this case is running another instance of the same application (which is very well possible on macOS). Would be nice if 1Password would know what instance I was coming from, and return to the correct one.Kolide Custom Checks?
Hi everyone, We have rolled out 1Password XAM and are really liking the Kolide Device checks. However we are running into edge-cases where we need to configure some custom checks and are struggling a bit. For example, we want to allow people with devices owned by other (partner) organisations access to some of our Kolide-protected apps. They have been allowed by their admins to install Kolide but they use a different EDR product that is not covered by the supplied checks. (Ie we use Crowdstrike Falcon, they use Palo Alto Cortex) Has anyone worked out a way to implement this sort of thing? Both in terms of a custom checks for Cortex and an either/or setup for EDR.
