Level up your business security with free, on-demand training and certification. Explore 1Password Academy today →
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?
SSH agent not working from `.ssh/config` in macOS
This worked until recently but I'm no longer able to load identities when using the following in my `.ssh/config` file: Host * IdentityAgent "~/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock" $ ssh-add -l The agent has no identities. But I can confirm it works fine with: SSH_AUTH_SOCK=~/Library/Group\ Containers/2BUA8C4S2C.com.1password/t/agent.sock ssh-add -l I've double checked the paths and permissions on the .ssh/config file but can't figure this out. Trying to figure out if this is a 1Password issue or an SSH issue. Seems like the latter. Any ideas?
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.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.
Concatenate password with OTP
Hello dear community, Yes, I know, I'm the N-th voice asking for this, and I know it becomes some sort of annoying noise, but please understand that the lack of this feature is such a speed bump in daily activity. Concatenating password and OTP is such a basic/common thing in many organisations. I am forced to use some other pwd manager for this purpose only, and I'm starting to look at this new one in all regards, because is cumbersome to have 2 of them. There is only so much a password manager can do, and the list of differentiating features is running thin. There is a point after which things like these matter a lot in the decision making process for a person, to use 1Password or to use something else. Please please please, pretty please, add this feature. It is such a pain to use 1password with (without exaggeration) 15+ VPN tunnels. 1Password Version: 8.10.7 Extension Version: Not Provided OS Version: macOS 13.4 Browser:_ Not Provided Referrer: forum-search:https://1password.community/search?Search=concatenation
CLI Slow Performance
I have the 1Password desktop app installed and up to date on my macBook Pro, the `op` CLI is also installed, up to date, and working properly. All expected CLI queries work but they are surprisingly slow. After a bunch of trial and error, it seems that it is making a round-trip online as part of every single CLI query. I added the --debug flag and I can see cache hits, but the round trip online is still occurring. Disabling the network interface causes all queries to fail. Is it possible to get the 1Password CLI working fully offline to avoid all of this unnecessary round-trip business? Surely with the desktop app installed and CLI integration turned on, there has to be a way to make efficient (and offline) use of my 1Password vaults. Otherwise automation tasks that require secrets are simply too cumbersome to handle with 1Password, and I will require a secondary solution. And in that case, I may as well give up on 1Password.
1Password Environments issue with VSCode and Claude Code Extension
I've noticed a curious issue in testing 1Password Environments in a repository where I'm editing with VSCode and using the Claude Code extension in VSCode. Since enabling 1P Environments, I've noticed that the Source Control sidebar gets stuck refreshing Git Status, and Claude Code slows or stalls. Running Claude Code outside of VSCode works fine (as does using Git in Terminal, and so I wonder if this is a VSCode issue? I have the VSCode 1Password extension, as well as the Claude Code for VSCode extension, among others. Happy to provide other details if you can let me know what would help.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!