Level up your business security with free, on-demand training and certification. Explore 1Password Academy today →
Domain Migration/Merge
I am not sure if there was an option, may of the settings became unavailable once 1P was connected to an IDP(Rippling). 1- We are rebranding and migrating from domain W to domain A, is there a way to rename users from user @ w.com to user @ a.org while keeping their access and accounts? 2-I've also seen a few users having both a.org and w.com accounts, is there a way to merge the two under a.org? 3-When a user is offboarded they may have passwords not saved in a shared vault, I would manually login as the user to access those. Is there an admin tool/function to transfer those vault items to their manager? Thanks!
Prioritizing Multiple Accounts
I am the travel arranger for my family, so I have multiple accounts with one airline saved in my 1Password. The unfortunate bit is that now when I log into my account, 1Password chooses my kid's account as the default instead of mine. Is there a way to order them so that my account comes up as the default? If I could just ask it to not sync family's passwords to my phone, but leave them on my computer only, that would be another way to fix it.Quandry: I bought 1PW Forever Version but That Fails
I have thinking for a good while now that in spite of my judicious, careful decision making, I bought 1Password 7 as a lifetime product, and my thinking was that by investing upfront in the forever software, I would be smart. I have always been a 1PW fanboy, believing it offered huge value to my wife and I with our Mac computers and iOS items, seamlessly working together. Unfortunately, 1pw chose to move to a subscription model, and I have been left in the dust. 1PW7 only works on Safari and fails on Chrome. It still works on iOS. On one hand, I that 1pw was not honest with me, and they have chosen the big revenue direction. On the other hand, maybe I should forgive them since software does evolve. I'm interested in your thoughts on what I should do. Can two people share a single $2.99 monthly membership? We don't want two vaults: since we generally share a single password for websites like Amazon, a single membership is better than two.
Login QR Code Content
Hi 1Password Team, I'd like to request a small change to the login via QR experience that should improve UX by quite a bit: the data presented in the login QR should contain 1Password-specific URL information that allows the user to initiate login by simply scanning the code itself rather than opening the 1Password app and choosing the QR Code option. To expand on this a bit, here's what's presented in the 1Password login QR code (data obfuscated obviously) k9F_aZ3mQx7R2pL8vD1sWcT0uYhG5eJ4nK6bCqXrM-Vt8PzU1wEoI9fS_dA2HjN7yL3gR5xB0kQv6mT4pZ1uWc8D9eF2aYh7J3sXnVyefhdfgw When scanning this QR code, any phone will attempt to search Google for this long random string. This is obviously not ideal. For a better UX example, look at the data contained in Steam or Discord's login QR codes: https://discord.com/ra/obb6XZfsdfP67eMtNgy36zCQt5fd9kshasdftZxPRwQ https://s.team/q/1/103748407414622342091 Would it be possible for the 1Password QR code to be updated to more closely match this functionality? Even presenting the data in the format of a custom URL scheme (as below) would be more helpful, as users with the app installed would still be prompted to open the link in 1Password via normal QR scanners. 1password://k9F_aZ3mQx7R2pL8vD1sWcT0uYhG5eJ4nK6bCqXrM-Vt8PzU1wEoI9fS_dA2HjN7yL3gR5xB0kQv6mT4pZ1uWc8D9eF2aYh7J3sXnVyefhdfgw Is there a plan for this functionality in the future?
op 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
Passport Dates
Those of us in the good ole USA are a little odd compared to most of the world. We use feet instead of meters, pounds instead of grams and we write dates in the format of mm/dd/yyyy. However, most of the world uses dd/mm/yyyy. When completing documents such as visas and even an application for USA passports. It would be great if dates on Categories/Passports appeared in the format dd/mm/yyyy so it would be easy to copy/paste into travel documents. Or at least allow me to type in a date like 31/7/2010 for July 31, 2010 in the Categories/Passwords. If you do this be sure to change the item heading to, for example, "date of issue, dd/mm/yyy" so it is clear to the user that the default formatting of this date is not being used in this specific instance. I would appreciate it if you would make this modification to 1Password. Thanks.Password and RSA Token fields
Hello, This is a screenshot of the fields I must fill in. If it does not show up it is a "Password" field above an "RSA Token" field. I must obtain the RSA Token passcode from the RSA app and enter it manually. This is the problem: When I use the 1P extension to autofill the password, it autofills the RSA field instead of the Password field. Highly annoying so I would be grateful for any suggestions. This is an iFrame which is why I am using the 1P extension to begin with. When I use MS Edge PW manager it autofills the correct password field so I guess I could use Edge PW manager just for inline webpages and 1P for everything else but I would prefer to use one or the other. (I disabled Edge PW manager when I started using 1P - does anyone have experience using both?) The password for the above field is the same as the password for the main webpage. Ideally it would just autofill but I understand there is a security reason preventing this. I understand MS Edge PW manager does not have the same security issues because it created the browser and can handle tricky field detection better than 3rd party apps. Thank you.Visit 1Password at MSP Summit 2026
Hi everyone, We're excited to be heading to MSP Summit 2026 in Las Vegas from April 13–16. If you're planning to attend, we'll be at booth MSP67 and would love to see you! We're happy to field questions about 1Password Enterprise Password Manager - MSP Edition, learn how we can help you support your clients' security needs, or whatever is on your mind in the world of cybersecurity.
