Arch Linux User Repository

As of the 2.24.0-2 release, Zsh shell completion is no longer provided by the package to mirror the official packages. Users that wish to use shell completion can add a line to their shell's dotfile.

See the official docs for instructions specific to your shell: https://developer.1password.com/docs/cli/reference/commands/completion/

It is recommended to verify the authenticity of the binary by using Agilebits's PGP code signing key. Their public key ID is published in the install documentation. Agilebits recently renewed their PGP key; if GPG reports the key has expired, simply run the receive command again and trust as you see fit.

gpg --receive-keys 3FEF9748469ADBE15DA7CA80AC2D62742012EA22

Hey @Sling, I tried to replicate that error message from a brand new installation of the 1Password desktop app and the CLI on a completely fresh VM, but was unable to reproduce.

After installing the 1Password desktop app via its AUR package and signing in, the settings/settings.json file was created with 0600 permissions and the CLI integration worked as expected after enabling through the desktop app.

$ ls -al ~/.config/1Password/settings
total 12
drwxr-xr-x  2 testuser testuser 4096 Mar 18 10:11 .
drwx------ 14 testuser testuser 4096 Mar 18 10:13 ..
-rw-------  1 testuser testuser  413 Mar 18 10:12 settings.json

I had an issue with the cli and desktop integration as well.

I was able to get somewhere by running op --debug vault list, and was given the following debug output.

11:10AM | DEBUG | Skipped loading desktop app settings file. The desktop app might not be installed: read file: Can't continue. We can't safely access "/home/sling/.config/1Password/settings/settings.json" because its permissions are too broad. Change its permissions to 600 and try again.

Setting the permissions to 600 like the output said instantly got the integration working.

I never set the permission for this file so I am confused why this was an issue at all.

@rnestler - strange that you ran into that issue recently. An issue with the onepassword-cli having a GID of less than 1000 should have been fixed in March 2022.

@slurpee Looking at my /var/log/pacman it seems that the first time I installed 1password-cli was indeed before that:

[2022-02-16T09:30:34+0100] [PACMAN] Running 'pacman -U --noconfirm --config /etc/pacman.conf -- ~/.cache/yay/1password-cli/1password-cli-1.12.4-1-x86_64.pkg.tar.zst'

So this explains it.

@rnestler - strange that you ran into that issue recently. An issue with the onepassword-cli having a GID of less than 1000 should have been fixed in March 2022.

I'll run some extra tests on some clean VMs to make sure that wasn't a one-off issue.

Did anyone get the integration with the desktop app to work? If I try to enable it in the desktop app I get the following error:

error initializing client: connecting to desktop app: read: connection reset, make sure 1Password CLI is installed correctly, then open the 1Password app, select 1Password > Settings > Developer and make sure the 'Integrate with 1Password CLI' setting is turned on. If you're still having trouble connecting, visit https://developer.1password.com/docs/cli/app-integration#troubleshooting for more help.

The desktop app shows the following output:

WARN  2026-02-03T10:46:56.698+00:00 runtime-worker(ThreadId(8)) [1P:op-ipc/src/ipc/unix.rs:402] invalid group attempted to connect, rejecting remote
INFO  2026-02-03T10:46:56.699+00:00 runtime-worker(ThreadId(8)) [1P:native-messaging/op-native-core-integration/src/lib.rs:597] Extension connecting.
ERROR 2026-02-03T10:46:56.699+00:00 runtime-worker(ThreadId(8)) [1P:native-messaging/op-native-core-integration/src/lib.rs:881] Failed to accept new connection.: PipeAuthError(NoCreds)

AI was able to solve it:

1. The GID "Higher than 1000" Rule

On some Linux systems, if the onepassword-cli group was created with a GID lower than 1000 (a system group), the desktop app may reject the connection for security reasons.

Check your group ID:
Bash

getent group onepassword-cli

If the number at the end is less than 1000 (e.g., 950), you should change it:
Bash

sudo groupmod -g 1005 onepassword-cli

After changing the group ID of onepassword-cli the integration did work.

@chrko - strange that you're running into that. Albeit a historical feature, gpg may assume the first argument to --verify is a detatched signature, then it will try to assume the signed data by stripping some suffixes from the first argument to --verify (--verify-files is just shorthand for --multifile --verify).

example, gpg assuming signed data:

$ gpg --verify-files src/op.sig

gpg: assuming signed data in 'src/op'
gpg: Signature made Tue 19 Aug 2025 11:22:08 AM PDT
...

Going through the gpg man page: it heavily discourages relying on that historical feature and to explicitly specify the signed data, it mentions --multifile may not be used to verify detached signatures, and plainly, there isn't a reason to use --multifile when there's only one signature to verify.

I'm in agreement that it probably should be changed to gpg --verify ${srcdir}/op.sig ${srcdir}/op. 2.32.0-2 will be released shortly with this change; please let me know if there are further issues.

Since quite a while I have trouble with verify the GPG signature as done in the PKGBUILD:

gpg --verify-files src/op.sig

gpg: no signed data
gpg: can't hash datafile: No data

instead I have to do the following

gpg --verify src/op.sig src/op

gpg: Signature made 2025-08-19T20:22:08 CEST
gpg:                using RSA key 3FEF9748469ADBE15DA7CA80AC2D62742012EA22
gpg: Good signature from "Code signing for 1Password <codesign@1password.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 3FEF 9748 469A DBE1 5DA7  CA80 AC2D 6274 2012 EA22

Can we change the approach in the PKGBUILD?

@slurpee Great, thanks for explaining.

@jacek2v - that's the expected output and the warning is benign.

"Good signature from" indicates the signature on the file matches the public key you're verifying against and you can trust the archive as being from Agilebits.

The warning is because you haven't signed ("certified") Agilebits's public key with your own private key (or a key you trust in your web of trust - "a trusted signature"). If you don't intend to use PGP other than validating the signature on files, you can safely ignore the warning and continue with installation.

gpg: assuming signed data in '/home/jacek/.cache/yay/1password-cli/src/op'
gpg: Signature made śro, 28 maj 2025, 12:15:49 CEST
gpg:                using RSA key 3FEF9748469ADBE15DA7CA80AC2D62742012EA22
gpg: Good signature from "Code signing for 1Password <codesign@1password.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 3FEF 9748 469A DBE1 5DA7  CA80 AC2D 6274 2012 EA22

any tips on what to do with this?