Protect what matters – even after you're gone. Make a plan for your digital legacy today.
op CLI hangs on macOS Tahoe
macOS: 26.3.1 (a) (25D771280a) op version: 2.33.1 A few days ago, I upgraded the CLI from Homebrew, and all my Terminal sessions started to hang randomly from time to time. So I can no longer use it in the scripts anymore. I tested across multiple Terminals (Warp, macOS Terminal, iTerm) to make sure it wasn't isolated to a given terminal. I tried to research online, and I found https://github.com/openclaw/openclaw/issues/55459 which solved my problem, at least for now. I had to add that `export OP_CACHE=false`, so it seems that it wasn't related to my computer per se (to be clear, it is NOT about openclaw in my case) I can't find any thread in the forum, but ideally, `op` fixes the situation.
Getting rid of my individual account. I have a family account now.
I had an individual account, which I upgraded to a family account. ages ago. When logging into the program, it frequently shows both icons - I have nothing in that old individual account, but the program asks me for my old individual account's secret code (which I no longer have either) but I can't get rid of it. When doing a log in to the extension, when both icons are showing, it assumes I'm trying to open the individual account, and then fails, when I don't have for my old secret key. Then I have to click on the family icon, and then enter the password, and it opens, but it's an extra unnecessary step. How to get rid of it?1password locks within 10 seconds on High Performance or Dynamic resolution screen share on macOS
As the subject notes, I've noticed 1password locks itself within about 10 seconds regardless of what I've set the auto-lock setting to. This makes copying and grabbing passwords, otp codes etc very difficult as I need to do it within 10 seconds of opening 1password. This has been happening for quite some time (6+ months at least) when I run screen shares with a remote macOS host via the screen share app using High Performance or Dynamic Resolution. The issue does not occur if I change from High Performance to standard in the macOS screen share app. High Performance is useful as it adjusts the remote display to match the display I'm using on my local machine. Which makes needing to switch back to standard - not ideal. The remote machine display does not scale nicely if in standard screen share type mode. I was wondering if anyone else has seen this issue? Remote Mac is running MacOS 15.6.1 1password ver. 8.11.6
SSH Agent Forwarding to Remote Mac
Okay! I have a Mac Mini that I use as a home server (it was effectively free after trade ins of old stuff). I do have 1Password and its SSH agent running there for when i'm using it with a screen attached, but I'd like to be able to initiate 1Password requests when SSH'ed into the box as well so i can perform `git` operations in particular. I have tried https://developer.1password.com/docs/ssh/agent/forwarding/#remote-workstation and to an extent it works. ssh -A my_name@macmini.local cat ~/.ssh/config # Output, showing we are trying to force using SSH_AUTH_SOCK # Match host * exec "test -z $SSH_TTY" # IdentityAgent "~/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock" echo $SSH_AUTH_SOCK # /Users/my_name/.ssh/agent/s.czyqavwOqO.sshd.RviXimjiEr So I can see that I'm getting some kind of agent socket attached appropriately. I've configured the `.ssh/config` to not use the IdentityAgent when over SSH (it's not commented out in the actual file, just commented here for display purposes in the code block). However, when trying to run a git command, it's like SSH doesn't even try to use the auth socket for pulling data and `ssh-add -l` is equally unhelpful. ssh-add -l # The agent has no identities. git pull # git@github.com: Permission denied (publickey). # fatal: Could not read from remote repository. # Please make sure you have the correct access rights # and the repository exists. I am sure I'm just missing a configuration of some kind somewhere but I am at a loss for what it could be. Happy to provide other debug information from either the host or the remote Mac mini as needed.
SSH Agent forwarded to Docker container only attempts to use the first SSH key
I have the SSH agent forwarded into a Docker container with the following config: volumes: - '~/.ssh:/.ssh:ro' - '~/.ssh/known_hosts:/.ssh/known_hosts:rw' - '${SSH_AUTH_SOCK_HOST:-/run/host-services/ssh-auth.sock}:/ssh-auth.sock:ro' environment: SSH_AUTH_SOCK: /ssh-auth.sock And the IdentityFile symlinked in an entrypoint script: mkdir -p "$HOME/Library/Group Containers/2BUA8C4S2C.com.1password/t" ln -sf "$SSH_AUTH_SOCK" "$HOME/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock" This is working and if I run "ssh-add -l" inside the container, I can see all the available keys. However, whenever the container requires SSH, the 1Password prompt is always for the same key (the first key listed by "ssh-add -l") and not the actual required key.
SSH config managed from 1Password - alternative to SSH Bookmarks
(Mods: feel free to remove this if it's not appropriate here) I gave SSH Bookmarks a try but found it didn't quite cover my needs. No password/OTP auth, no way to use arbitrary SSH directives, no per-machine filtering, ... So I ended up building a small OSS tool called ssh-concierge that takes a similar approach but goes a bit further: it treats 1Password as the single source of truth for your entire SSH config, not just key-to-host mapping. In case it's useful to anyone else: https://github.com/bedezign/ssh-concierge Happy to answer questions!
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
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.
op cli read file
Hi, i'm not sure i missed something but reading files with op cli doesn't work anymore, but reading a field from the same entry still works: op --account https://#org1#.1password.eu read "op://#vault3#/#item8#/#field1#" passwordbla op --account https://#org1#.1password.eu read "op://#vault3#/#item8#/#filename1#" [ERROR] 2026/03/12 17:24:01 could not read secret 'op://#vault3#/#item8#/#filename1#': Authentication: (403) (Forbidden), You aren't authorized to access this resource. op --account https://#org1#.1password.eu document get #id# [ERROR] 2026/03/12 17:36:35 (403) Forbidden: You aren't authorized to access this resource. This worked before, so i'm kinda puzzled what is happening.
