Level up your business security with free, on-demand training and certification. Explore 1Password Academy today →
Secret reference to website url
Hi, Is there any plan to implement secret reference to website url? Currently `urls` is an array of objects "parallel" to `fields` array of ... field objects. So I assume that because of this you can't use secret reference syntax to point them out i.e. via label like `website`. Hopefully I'm wrong and it's already implemented ... Cheers, Łukasz
Allow Warp as terminal to open SSH URLs
http://warp.dev is a popular terminal emulator that support both MacOS, Windows and Linux. It's popular and should be considered relevant enough. It would be great to support this Terminal within Settings -> Developer -> SSH Agent -> Advanced -> Open SSH URLs with.
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 experienceEnvironments 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.
1Password 'Environments' and monorepos/collocated deployment configuration
I'm fiddling with Environments today to see how it would work for my workflows, and immediately ran into two fairly significant blockers: ## Multi-environment orchestration The only way I can see to get an environment-ID into an `op run` command is as a flag/env-var pre-dispatch; but for something like Ansible, where an entire inventory of tasks require a complex mapping of projects/apps/secrets/teams, that would require centralizing all of the "environment IDs" into one top-level invocation, irrespective of what actual tasks the given Ansible command might run. (This isn't Ansible-specific, "ansible" here could be any complicated orchestration tool that makes intelligent decisions about what to do for multiple potential environments.) Yes, I'm sure the blessed path, or what would be ideal for 1P, is that each possible orchestration tool in existence use the 1P SDK, have a built-in, or a plugin, or something like that, so that 1P is separately queried for each target/environment - but there will always be *some* tool that doesn't (up to an ad-nauseum target of "all of our deployment is bespoke by scripting.") At the moment, this situation is still better served by the previously-extant `op://` references in static env-files: they're "discoverable" during the process, in that anything/everything present in the environment is substituted at launch-time; but that's also worse in its own way - they're less isolated, and it leaves a similar "collect all the environment for all possible targets first, before executing the orchestrator." I don't necessarily have a specific feature-request or a way I imagine this working, right now; I just wanted to surface the annoyance for you to consider as you're working on the feature. (Related issue, similar vein, but not exactly the same architectural problem - there's only one `OP_ENVIRONMENT_ID` env-var; and while the `op run` can take multiple environment-flags, that's again a single-point-of-invocation issue. Ways to construct partial environment-based assignments pre-invocation is missing here, unless you store them manually and construct some method of passing them to `op run` - i.e. there's no equivalent of `op://` references, where multiple different scripts and wrappers can all happily contribute multiple `op://` references into the environment without coordinating, and one final `op run` can consume/resolve all of them for some sort of commit/apply process.) ## Duplication of secrets This one is the much bigger one, and kinda a dealbreaker, at least for me. For basically any given secret, I *already* have a central, authoritative 1Password entry as the source-of-truth for that - it has version-history, shared notes, access permissions for people, it autofills browsers and logins and CLI invocations ... but at the moment, "1Password Environments" only allows me to put in 'dumb strings' as variable-values. Which means that I need to, say, *duplicate* a database-user password in both 1. a 1Password vault-entry, and 2. a 1Password environment-variable. (... and then document somewhere that it's been duplicated; and establish process to make sure anybody modifying it knows to go modify both; and, and, and ...) I assumed when starting this out that the entire point of 1Password environments would be, effectively, something like a templating system: include, inline in the definitions, the equivalent of `op://` references to other *existing* secrets, such that they're filled in when actualized onto the filesystem or requested from SDK apps. (Think, "username" and "password" are already in a database vault-entry; so the `DATABASE_URL` env-var configures how to construct the database-url from those keys.) Without that functionality, I'm actually a little lost as to the value/purpose of environments (not to criticize anyone's hard work, or anything; I'm sure there's a pictured use-case that makes sense, I'm just not currently managing to see it, haha.) So, the request here is a little more direct: let me configure references to other 1Password items in environment-variables - at a minimum as a 1:1 correlation (i.e. `DB_USER` being configured directly to `op://Team Secrets/Database - Prod/Postgres/username`); but ideally, with some minimal templating, so additional content/simple structure can be hardcoded into the env-vars that are *mostly* derived from secrets (Postgres connection-strings/URLs; or derivation from other env-vars to avoid duplication on that end either, such as configuring `USER_PW` to `op://Team Secrets/${HOSTNAME}/password`.) Hope this is helpful feeback about the issues somebody ran into in the real-world trying to apply this! I *do* love the promise of ditching env-files-full-of-`op://`-references-hardcoded-into-repos, in favour of something more auditable / sited-with-the-secrets-in-question / dynamically-configurable.
Sharing password directly (without "copy link")
I'm looking to share a key which will be on a set rotation with an account outside of our organisation (and therefore our 1Password tenant). Right now I can only see the option to Copy Link for the key which I would then have to manually (or create an automation for) to add to an email or similar to send over to the client. Is there any way within 1Password to share this credential without the manual step of copying the link to the password and then sending to the recipient elsewhere?
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.
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.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!Feature Request: Can we get a gh auth login style flow for the CLI?
Hi 1Password team, I’m hitting a major wall with the CLI when trying to use it with AI coding agents (like Claude Code, Cursor, or Linear Agents). Right now, op seems to assume that the person running the "op run" command is always sitting right there at a TTY with a keyboard. But when I’m running an agent in a headless container or a remote environment, the CLI just hangs because it’s waiting for a password or a biometric prompt that it can’t reach. I really don't want to use Service Accounts for this. Giving an autonomous agent a long-lived, static token feels like a massive security step backward. I want the agent to be able to "ask" me for permission. What I'm looking for: A way to do something like op login --browser. It would give me a URL/code (exactly like how aws sso login or the GitHub CLI works), I click it on my host machine, auth in my browser with TouchID, and the agent gets its session token. Are there any plans to support an OIDC-style "Device Authorization" flow?