v2 Client unable to connect to Desktop App

jeffutter

Hi there. I'm testing out the new v2 cli and it seems to be unable to connect to the desktop app.
I have enabled all the 'developer' settings in the v8 beta app. Any suggestions on how to debug this?

❯ op -v
2.0.0

❯ op account add
Biometric unlock integration with the 1Password app is enabled. Add an account through the 1Password app.

To learn how to add an account to the 1Password app, visit: https://support.1password.com/add-account

❯ op account list
[ERROR] 2022/03/16 13:10:30 connecting to desktop app: not connected

nearly all commands return connecting to desktop app: not connected

---

1Password Version: 8.6.0
Extension Version: 2.3.0
OS Version: 12.3

Justin.Yoon_1P

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?

jeffutter

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

Justin.Yoon_1P

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.

jeffutter

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

Justin.Yoon_1P

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.

zcutlip

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:

❱ 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

Joris_1P

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

sdahlbac

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

Horia.Culea_1P

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

ehllie

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.

Joris_1P

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 Requirements tab for Linux 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

ehllie

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:

programs = {
  _1password.enable = true;
  _1password-gui = {
    enable = true;
    polkitPolicyOwners = [ "my-user-name" ];
  };
};

In hindsight, the documentation available from nixos.org 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!

Joris_1P

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