v2 Client unable to connect to Desktop App

Good to hear you got it to work!

To make sure that others don't run into similar problems with NixOS in the future: is there anything that we could add to our documentation (on developer.1password.com) that could make it easier to get the CLI to work on NixOS? Would it be enough to add the snippet you shared and tell users to add that to environment.systemPackages?

Joris

Ah, that's true. Turns out I installed 1password somewhat incorrectly. I only added _1password and _1password-gui to environment.systemPackages, but all that did was add their binaries to my path. The correct way to install them, with the ability to use the gui integration, was to enable them in the nixos configuration like so:
nix
programs = {
_1password.enable = true;
_1password-gui = {
enable = true;
polkitPolicyOwners = [ "my-user-name" ];
};
};

In hindsight, the documentation https://search.nixos.org/options?&query=_1password even mentions my specific issue, but I suppose I did not read it carefully enough. But it all works now at least. Thank you for the quick response!

Hey @ehllie!

I have good news for you: on Linux there is actually no requirement for the CLI binary to be in /usr/local/bin/op (the online documentation seems to contradict this; I'll get that fixed 😀).

On Linux, it is important that the CLI is owned by a group named onepassword-cli and has the setgid bit set. Check the https://developer.1password.com/docs/cli/get-started#requirements in the Getting Started guide how to do that (you can ignore the part about the /usr/local/bin/op).

Let me know if that helps.

Joris

It would definitely be great to have this behavior changed. I'm encountering the same issue on NixOS, and without changing my entire workflow I don't really have a way of using op with biometric authentication. I've tried symlinking /usr/local/bin/op to the store path where i have it installed, or even copying it there with systemd tempfile rule, but neither of those had any effect.

Thanks for raising this here, sdahlbac!
We'll make sure to post an update, once we have any updates pertaining to this.
Thank you for your patience!

Best,
Horia

Just hit this as well. I would love to be able to have op v2 in /usr/local/bin/op, but for various legacy reasons that cannot be fixed in the near future, I need op v1 as /usr/local/bin/op

Hi Zach,

You are right that the sandbox exception in the entitlements is the origin of this requirement. We are investigating our options to make this a bit more flexible.

Joris

I encountered this as well. I believe it's because of 1Password's entitlements, or more specifically, those of 1Password.app/Contents/Library/LoginItems/1Password Browser Helper.app:

console
❱ codesign -d --entitlements - /Applications/1Password.app/Contents/Library/LoginItems/1Password\ Browser\ Helper.app
Executable=/Applications/1Password.app/Contents/Library/LoginItems/1Password Browser Helper.app/Contents/MacOS/1Password Browser Helper
[Dict]
[Key] com.apple.security.app-sandbox
[Value]
[Bool] true
[Key] com.apple.security.application-groups
[Value]
[Array]
[String] 2BUA8C4S2C.com.1password
[Key] com.apple.security.temporary-exception.files.absolute-path.read-only
[Value]
[Array]
[String] /usr/local/bin/op


I'm not sure, but I think it may be possible to grant permissions to other paths via a finder dialogue or possibly a TCC request? Not sure of the implications here of interacting with the SEP for Touch ID though.

It would be nice to be able to run op from alternate (explicitly user approved) locations. I keep an archive of op cli versions around for pyonepassword, to be it supports new features and that it fails gracefully where appropriate.

Cheers,
Zach

Hey @jeffutter ,

I'm very happy to hear you've resolved the issue!

We are working to ensure that the directory restriction is removed, so keep an eye out on the upcoming changelogs. For now, it is to ensure security between communication of the 1Password app and the CLI.

@"Justin.Yoon_1P" I think I actually just figured out the issue here. The upgrade instructions here: https://developer.1password.com/docs/cli/upgrade/ clearly indicate

For macOS 1Password CLI 2 has to be moved exactly to /usr/local/bin/op.

The other instruction pages, such as https://developer.1password.com/docs/cli/get-started/ indicate

Install 1Password CLI in the default location: /usr/local/bin.

Without the exactly distinction.

I had installed the cli with nix and home-manager which installs the binary somewhere in /nix and symlinks it to /Users/<my-user>/.nix-profile/bin/.

My guess is that if it's not in /user/local/bin then it can't be verified as an authentic binary for biometric things - similar to how the browser extension won't work if your browser isn't installed in /Applications (ran into that problem too).

I removed the installation with nix and installed with brew and it seems to be working now.

Perhaps the area that outputs the connecting to desktop app: not connected error could add a warning if your op binary isn't in /usr/local/bin.

Anyway. Thanks for the help on this.