Level up your business security with free, on-demand training and certification. Explore 1Password Academy today →
Is it possible for 1Password CLI running on WSL to connect with 1Password hosted on Windows?
Right now I can access 1Password on my WSL Debian installation using the CLI. But I have to enter my master password even when Windows is authenticated. I was just curious if it's possible to connect the two (a-la the SSH agent forwarding magic outlined here - https://1password.community/discussion/128023/ssh-agent-on-windows-subsystem-for-linux) 1Password Version: Not Provided Extension Version: Not Provided OS Version: Not Provided Browser:_ Not ProvidedCLI Offline Mode
Hi team & community 👋 I know this was posted years back but I am wondering if the team has any appetite to allow for loading secrets from the CLI without internet access? Considering we can use the 1Password Desktop app offline I don't see why the CLI can't have the same functionality. Happy to discuss this in more detail to help this become a reality. 1Password Version: Not Provided Extension Version: Not Provided OS Version: Not Provided
CLI not talking to 1Password desktop
Hi folks, I'm running into some issues when I run op commands, even after I uninstall and re-install both the CLI and 1Password desktop binaries, as well as checking/unchecking the "Integrate with 1Password CLI" option in the desktop app. Any help troubleshooting would be greatly appreciated: $ op item get test_item --vault test_vault --fields label=password [ERROR] 2024/11/04 15:43:52 error initializing client: connecting to desktop app: received unexpected response from 1Password app. Please make sure 1Password CLI and the 1Password app are up-to-date. 1Password Version: 8.10.50 Extension Version: 2.30.1 OS Version: Ubuntu 24.04.1 LTS Browser: Not Provided
Feature Request: First-Class Support for Dev Containers and 'op' CLI
Feature Request: First-Class Support for Dev Containers and 'op' CLI Summary We request 1Password to add native support for Development Containers (Dev Containers) and improve integration of the 'op' CLI within these environments. Background Dev Containers are an increasingly popular approach to standardizing development environments across teams. They allow developers to use a consistent, reproducible setup by running all development tooling inside Docker containers. This approach has gained significant traction, especially with the adoption of Visual Studio Code's Dev Containers extension. Current Limitations The 1Password CLI ('op') does not function seamlessly within Dev Containers. Authorization for 'op' inside a Dev Container is treated as a separate computer, complicating the user experience. Existing solutions like 1Password Connect and Service Accounts don't address this use case adequately. Requested Features Native Dev Container Support: Develop an official integration that allows the 'op' CLI to work seamlessly within Dev Containers. Authorization Continuity: Implement a mechanism that allows the 'op' CLI in a Dev Container to utilize the authorization from the host machine, similar to how Git and SSH work in Dev Containers. Official Documentation: Provide comprehensive guides and best practices for using 1Password within Dev Container environments. Use Case Developers using Dev Containers should be able to: - Access their 1Password vault securely from within the container - Use the 'op' CLI for tasks like secret injection into environment variables - Maintain a seamless workflow without repeatedly authorizing or switching contexts Benefits Improved Developer Experience: Streamline the use of 1Password in modern development workflows. Enhanced Security: Encourage the use of secrets management in containerized development environments. Consistency: Align 1Password's capabilities with other tools that already support Dev Containers. Technical Considerations The solution should work with various Dev Container implementations, focusing on the Visual Studio Code extension as a primary target. Consider leveraging existing authorization mechanisms used by other tools in Dev Containers (e.g., SSH agent forwarding). Ensure that the security model maintains 1Password's high standards while enabling this new use case. Conclusion Adding first-class support for Dev Containers would significantly enhance 1Password's value proposition for development teams and individual developers embracing modern workflows. We believe this feature aligns well with 1Password's commitment to security and user experience in the development ecosystem. We appreciate your consideration of this feature request and look forward to the possibility of seeing it implemented in future releases. 1Password Version: Not Provided Extension Version: Not Provided OS Version: Not Provided Browser: Not Provided
1Password CLI Biometric Authentication in Dev Container
I like to develop using https://code.visualstudio.com/docs/devcontainers/containers on my MacBook, and I love to be able to load secrets dynamically with the 1Password CLI. Using the 1Password CLI works great when I run commands directly on my mac. However when I setup a DevContainer to develop inside of, the 1Password CLI is not connecting. 1Password SSH biometric authentication still works, but I assume that is because the DevContainer is able to connect to the ssh socket. Can I mount the 1Password CLI socket into the DevContainer so that when I run "op" commands it is able to connect to my host machines 1Password Desktop App? Where is the 1Password CLI socket so that I might mount it? I should also note that the DevContainer Distributor ID: Debian Description: Debian GNU/Linux 12 (bookworm) Release: 12 Codename: bookworm 1Password Version: 1Password for Mac 8.10.36 (81036049) Extension Version: CLI Version 2.29.0 OS Version: macOS 14.5 Browser: Not Provided
CLI hangs when requesting items
the cli had been working without issues for a while but about a day ago it began to indefinitely hang when fetching an item. When I run: op item get XXX --otp --debug I get: 9:35AM | DEBUG | Session delegation enabled 9:35AM | DEBUG | NM request: NmRequestAccounts 9:35AM | DEBUG | NM response: Success 9:35AM | DEBUG | NM request: NmRequestAccounts 9:35AM | DEBUG | NM response: Success 9:35AM | DEBUG | account not signed in, filter=XXXX latest_signin_user=XXXXXXXXXX 9:35AM | DEBUG | not signed in reason: session file not found 9:35AM | DEBUG | NM request: NmRequestAccounts 9:35AM | DEBUG | NM response: Success 9:35AM | DEBUG | NM request: NmRequestAuthorization 9:35AM | DEBUG | NM response: Success 9:35AM | DEBUG | NM request: NmRequestAccounts 9:35AM | DEBUG | NM response: Success 9:35AM | DEBUG | NM request: NmRequestDelegatedSession and it just hangs there. Any idea of what could be wrong here? 1Password Version: 8.10.3 (81003012) Extension Version: 2.15.0 OS Version: macOS 13.2.1 (22D68) Browser:_ zsh
"op read" is pretty slow, ~700ms per invocation
Hi all, I've noticed that op read is pretty slow, taking on the order of 700ms per invocation. Here's a benchmark using the https://github.com/sharkdp/hyperfine tool: % hyperfine --warmup 3 "op read op://private/op-test/password" Benchmark 1: op read op://private/op-test/password Time (mean ± σ): 717.2 ms ± 46.6 ms [User: 118.7 ms, System: 39.6 ms] Range (min … max): 640.8 ms … 782.3 ms 10 runs Reading a non-password field is about the same: % hyperfine --warmup 3 "op read op://private/op-test/username" Benchmark 1: op read op://private/op-test/username Time (mean ± σ): 733.2 ms ± 52.1 ms [User: 124.0 ms, System: 41.4 ms] Range (min … max): 680.8 ms … 815.0 ms 10 runs And using --cache does not seem to change anything: % hyperfine --warmup 3 "op --cache read op://private/op-test/password" Benchmark 1: op --cache read op://private/op-test/password Time (mean ± σ): 718.8 ms ± 50.3 ms [User: 119.6 ms, System: 39.6 ms] Range (min … max): 653.7 ms … 806.7 ms 10 runs This is on a 16-inch MacBook Pro with an M3 Max on Sonoma 14.4.1. I've installed op via Homebrew. I'm not sure what the expectation is, but this seems much slower than I expected. 1Password Version: 8.10.30 Extension Version: Not Provided OS Version: macOS 14.4.1 Browser: Not ProvidedAWS plugin MFA fails intermittently
When using the AWS plugin with MFA and profiles, about one in every 5 times it fails with this error: aws sts get-caller-identity --profile=profile [ERROR] 2024/05/06 12:44:59 could not run plugin AWS CLI: failed to provision credentials, encountered error(s): operation error STS: AssumeRole, failed to sign request: failed to retrieve credentials: operation error STS: GetSessionToken, https response error StatusCode: 403, RequestID: xx-xx-xx-xx-xx, api error AccessDenied: Cannot call GetSessionToken with session credentials Most of the time I can then run op plugin run --debug --cache=false -- aws ls s3 to correct the situation. New 1Password customer so all the newest Apps, it happens on Arch Linux and MacOS. 1Password Version: Not Provided Extension Version: Not Provided OS Version: Not Provided Browser: Not ProvidedCLI Offline usage
From the previous discussions regarding offline usage of the CLI (https://1password.community/discussion/130695/cli-offline-mode and https://1password.community/discussion/101326/offline-accessibility-of-local-vault) I gather that it's not on the roadmap at the moment, and I'd like to bring some more context for when the feature would be incredibly helpful. At work we are doing a lot of field work on systems that are airgapped (because they don't need internet access to begin with) or when we are troubleshooting systems that has lost their internet access. We are also heavy users of https://www.royalapps.com/ts/ and their https://www.royalapps.com/blog/dynamic-folder-integration-for-1password that relies on the CLI. The combination of Royal TS/X and 1password has been great for us so far, as it gives us a single source of truth for all connectivity details, and secure management of credentials, no matter what kind of device we're connecting to. It's just some situations that it doesn't cover without workarounds, and that's when we need to focus on the problem at hand the most. I hope this made sense! I understand that it's quite far from the always-connected world most of us live in, and we're not using the CLI in the CI/CD context it was built for. But we really like your product, and would love to like it even more. :) 1Password Version: Not Provided Extension Version: Not Provided OS Version: Not Provided Browser: Not Provided
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!
