v2 Client unable to connect to Desktop App

Hi @jeffutter

I would love to help you out, do you mind trying the op signin --debug command to run the signin process with debug logs?

Also, what OS are you experiencing these issues on? Does your hardware have a fingerprint reader?

Hey @"Justin.Yoon_1P" thanks for the help.

Where may I ask should the debug logs be output? In the console? When I run with --debug it's the same as without.


❯ op signin --debug
[ERROR] 2022/03/18 07:26:33 connecting to desktop app: not connected


This is on macOS 12.3 on a 16" MBP with a fingerprint reader.

I did notice one additional bit of information. If I turn OFF "Biometric unlock for 1Password CLI" in the app. I can then sign in

Hi @jeffutter ,

We have a few paths in biometric auth that we started logging debug messages for. If you hit any of those paths, it would've logged to stdout in your terminal, so I think the absence of logs can be telling here as well, as it would hint that it never entered some of these error paths.

While it's good to know you are able to use op with biometric auth disabled, we'll try to get it working for you. I'm going to look into this in detail and also bring in some colleagues who are more familiar with the feature as well, and will provide any updates here.

@"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.

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.

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

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

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

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

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.