Protect what matters – even after you're gone. Make a plan for your digital legacy today.
Multiple account support in op run
At present, op run supports injecting secrets into environment variables using the op://vault/item/field syntax. Where multiple accounts are in use, this means the vault needs to be in the account matching OP_ACCOUNT. I'm trying to remove reliance on any secrets on disk and it would be useful it supported multiple accounts. I'm wondering if adding an optional account to the URI syntax would be a good idea? It would look like op://account@vault/item/field and when no account is specified, it would use the existing logic for determining the account. I can see there may be issues when @ symbols exist in the vault names but perhaps it can fall back to current behaviour if the part before the first @ symbol doesn't match an account name in that case? Anyway, raising this as a suggestion because I see the request to support multiple accounts has come up several times before and of course breaking existing URI handling would be a blocker. As a workaround in the meantime, I just nest multiple invocations: op run --account Account1 --env-file account1.env -- op run --account Account2 --env-file account2.env -- the_real_command but it's a bit ugly!
op.exe considered harmful?
I’d like to raise a point about the current security model of op.exe, and how it affects protection against supply-chain or similar attacks. Consider a scenario where an attacker manages to execute malicious code locally, for example, via a compromised Python package. While this is often considered “game over,” in practice we still want to avoid being the easiest target in such situations. A common behavior of malicious payloads is to harvest local secrets. While 1Password provides some protection against direct file access, an attacker can simply invoke op.exe, which actually centralizes access to clear-text secrets in a very convenient way. Although op.exe prompts the user for permission, my understanding is that this permission applies broadly (e.g., to the entire account for a period such as 10 minutes). As a user, I can see which application is requesting access, but not which vaults or items are being queried. In practice, the application name (e.g., WindowsTerminal) is not very helpful in determining whether the request is legitimate. I’d be interested in others’ perspectives on this. Some potential improvements that seem valuable to me: When requesting permission, op.exe should provide more context (e.g., which vaults and items are being accessed). Users should be able to grant permissions at a finer granularity: not just account-wide, but limited to specific vaults or even individual items. Another useful feature would be the ability to mark certain items or vaults as excluded from programmatic access (via op.exe, and possibly browser extensions). Even better, this could be the default behavior, requiring explicit opt-in at the item level. I understand that such restrictions would be enforced client-side and therefore not fully robust. However, they would still meaningfully increase the effort required for a malicious local process to enumerate and exfiltrate secrets, and thus provide practical security benefits. Finally, it might be worth considering stronger protections at the vault level—for example, requiring explicit user authentication (master password, or even a separate password) before allowing access to secrets. This could apply not only to op.exe, but also to the interactive 1Password client.1Password Environments should enable grouping environments by service
Hi, The new .env management feature in 1Password is incredibly handy, and I can definitely see us adopting it for our backend services. It makes working with environment variables much more convenient. That said, I’d like to share some concerns regarding scalability. We have several services, each with multiple environments such as development, staging, production, and feature-specific environments. In 1Password Environments, these all of these environments appear side by side in a single list, regardless of which service they belong to. This results in naming schemes like "[Service]: [Environment]". While workable, this approach becomes harder to manage as we scale across multiple services. To illustrate, I’ve included a screenshot below showing what I anticipate the structure to look like in our setup. In this case, Service A and Service B have no relation to each other, yet their environments are intermingled. A way of grouping services would make this much clearer and easier to navigate. Best regards, Simon B. Støvring
FR: Allow Environments to reference Vault Items
Description: Currently, 1Password Environments and Vault Items are two completely separate systems with no connection between them. This creates a fundamental problem for professional workflows: Environments provide fast, secure secret delivery via Named Pipes – great for local development Vault Items provide rotation, audit trails, access control, and CLI management – great for operations But you have to choose one or maintain both in parallel, which means either giving up rotation or giving up fast secret delivery. Proposed Solution: Allow an Environment variable to be linked to a Vault Item. The Environment would act as a structured view over Vault Items, not a separate data store. Benefits: Single source of truth – secrets live in Vault Items, Environments just expose them Rotation works automatically – rotate the Vault Item, the Environment reflects the change immediately Audit trail remains intact – all access and changes tracked in Vault Items Named Pipe delivery stays fast – no change to the developer experienceFeature Request: Manage "Autofill Behavior" via CLI/API
Hi team, I’m requesting the ability to programmatically set Autofill Behavior (e.g., "Always fill on this domain," "Only on this exact domain," or "Never fill") using the 1Password CLI and API. Current Pain Point: While I can create and edit items via op item create/edit, there is currently no flag or field to define how the browser extension should handle autofill for that specific URL. This requires manual GUI intervention after an automated setup. Proposed Feature: Add a flag or JSON attribute to the CLI to toggle these settings. Example: op item edit "My App" --url "https://sub.dev.com" --autofill "exact-domain" Use Case: Security: Automatically enforcing "Exact Domain Only" for sensitive subdomains during vault provisioning. Automation: Fully configuring new items for team members without requiring them to manually adjust settings in the browser.
Environments should quote .env values
I just started experimenting with Environments to mange my .env files. I use https://direnv.net/ to load my .env files into my shell and it immediately started complaining. As it turns out, my previous plain text .env had quoted values in some cases, for instance a secret that contains a "&" and another one with ")". It would be nice if Environments either quoted values by default or offered the option to do so. Would also be nice if my #comments were preserved on import.
Environments feature request: Add notes to variables & insert them as comments in the final .env
Hey folks! I'm really liking the Environments Beta, but one thing I'm missing is the ability to keep the comments I had in my old manual `.env` file. For example I have an API key that has no indication of which actual account it's for, so it would be really nice to be able to add this as a note in 1Password and have it end up in the resulting .env file. So in this example, the "API_KEY" variable would have a note attached in 1Password that said "Associated account is frobulator@example.com" and the resulting .env file would look like this: $ cat .env # This file was generated by 1Password. Any manual edits will be lost. # For more information, visit: https://developer.1password.com/docs/environments/local-env-file BASE_URL=https://prod.example.com # Associated account is frobulator@example.com API_KEY=uophfpanfphbofsgfoibCVHDFBahpis1Password Environments Beta is awesome
Just wanted to drop some feedback after playing around with the new Environments Beta in 1Password. Honestly, I’m loving it so far. The local .env file mounting is just brilliant. Secrets are easy to access without having to run extra commands, but still secure – exactly what I want. Makes switching between machines seamless, too. A couple of things I’d really like to see next: 1. CLI Integration - being able to create/edit/list environments and variables from the terminal would make this so much more useful, right now, having to click around in the desktop app is a bit of a pain for dev workflows. 2. More integrations: AWS Secrets Manager is a great start, but would love to see GCP and other major providers such as GitHub, etc. A plugin system for integrations would be awesome also to help cover more niche players like Modal.com Overall, this is a huge step in the right direction for 1Password. Can’t wait to see where this goes next![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.Feature Request: GeneratorRecipe for Memorable Passwords
Currently in the API options for 1P Connect there is an ability to specify a "GeneratorRecipe" when creating a password for a record: https://developer.1password.com/docs/connect/api-reference/#item-generatorrecipe-object This is great for super-high-entropy random passwords but in some instances we would like to have the ability to specify that the generator create a "Memorable Password", as can be done in the 1P apps: Ideally this would then allow for specifying criteria similar to: "generate": true, "memorableRecipe": { "memorableRequirements": [ "HYPHENS", "CAPITALIZE", "FULLWORDS" ], "words": 4 } While this isn't needed all the time as the default 'generate' option is suitable in most scenarios, this would provide some extra flexibility. PS - In the same vein, it would nice to have this capability for the CLI's '--generate-password' option as well!! https://developer.1password.com/docs/cli/item-create/#create-an-item
