Protect what matters – even after you're gone. Make a plan for your digital legacy today.
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 experience
Feature 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=uophfpanfphbofsgfoibCVHDFBahpis
1Password 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
Password generator when exporting ssh keys
It would be nice to integrate the password generator when exporting ssh keys to create a random passphrase saved in the key entry in 1Password. The workflow for this is clunky currently as I create a new password field in the entry with a randomly generated password and then use that as the passphrase when exporting the key. Now, when the key is exported 1 password saves an entry of the passphrase used to export the key. Now I’ve got two entries for the same phrase. it would be a much simpler flow if the passphrase could be randomly generated inside the export key dialogue instead.What is an Agent Chassis?
Jeff Malnick’s post is confident. It’s also detached from how developers actually ship code today and made me furious.“Agent chassis” boils down to: the script that runs your agent. Fine. But the security layer argument collapses when the tooling underneath is fragmented.Right now you pick between CLI, shell plugins, service accounts, connectors, environments — each with different auth models, rate limits, edge cases, and silent failures. None cleanly support a headless agent workflow. I’ve built workarounds for my workarounds.Agentic coding made this obvious. Agents need real credentials at runtime. Not desktop popups. Not biometric prompts in a terminal.The community built unofficial MCP servers. Anthropic shipped 50+ connectors. 1Password isn’t there.The spec is public. It’s buildable. So—who’s shipping it?Automated bi-directional sync between 1Password and AWS Secrets Manager — is this actually possible?
Hey everyone, SRE at a small startup here. We've been using 1Password for a while and overall love it, but we're running into a friction point with our AWS setup that I'm hoping someone has solved. What we're trying to achieve: We want a proper bidirectional sync between 1Password vaults and AWS Secrets Manager. Specifically: 1Password → AWS SM: When someone on the team updates a credential in 1Password, it should automatically propagate to AWS Secrets Manager so our workloads pick it up without anyone having to manually copy-paste things. AWS SM → 1Password: We use AWS Secrets Manager's native auto-rotation for some credentials (RDS passwords, API keys, etc.). When AWS rotates a secret automatically, we'd want that updated value to flow back into 1Password so our employees can always go to 1Password as the single source of truth and get the current credential. On the new "Environments" feature (beta): We noticed the new Environments feature and got excited — it looked like exactly what we needed. But after digging in, it seems pretty limited right now. From what we can tell: There's no SDK support for managing environments programmatically There's no CLI support either (`op` doesn't seem to have environment management commands yet) Everything has to be done through the UI wizard This makes it really hard to automate. We provision new environments dynamically as part of our infrastructure-as-code workflows (Terraform), so we need to be able to create and configure environments programmatically. Is this on the roadmap? Are there any workarounds people are using? The SAML IdP requirement in Environments: Related to the above — the Environments setup wizard seems to require a SAML Identity Provider to be configured for each environment. We use Azure Entra ID as our IdP (federated through AWS Cognito), and we have a single IdP setup that covers all our environments. Is it actually required to have a separate SAML IdP per environment, or is there a way to reuse a single IdP across multiple environments? The wizard flow makes it seem like each environment needs its own IdP configuration, which would be a significant blocker for us — we can't dynamically spin up new IdP configurations every time someone creates a new environment in our platform. If this is a hard requirement, it basically rules out Environments for our use case entirely, since we'd need to automate IdP provisioning as part of environment creation, which is a whole other can of worms. Summary of questions: Has anyone built a reliable bidirectional 1Password ↔ AWS Secrets Manager sync? Especially the AWS SM → 1Password direction for auto-rotated secrets? Is there any programmatic/API access for Environments (SDK, CLI, REST API) that isn't documented yet, or is it genuinely UI-only right now? Is a separate SAML IdP per environment actually required, or can you reuse one IdP across environments? Thanks!
