I have run into this a number of times now, and it is frustrating because it slows my development work, particularly when I just want to use existing integrations in things like Ansible but also not rely on system dependencies like system python. It appears that the op cli communicates which process is calling it to the 1password desktop app, which then checks for root ownership of that binary.

My main test case that was simple to get going was running task (taskfile.dev) installed via asdf-vm (installed in my user directory). Running the op read command in a task cmds entry would result in failure:

WARN 2023-02-14T08:14:33.816 tokio-runtime-worker(ThreadId(5)) [1P:foundation/op-sys-info/src/process_information/linux.rs:247] binary permission verification failed for /home/$USER/.asdf/installs/task/3.17.0/bin/task
INFO 2023-02-14T08:14:33.816 tokio-runtime-worker(ThreadId(5)) [1P:native-messaging/op-native-core-integration/src/lib.rs:305] Extension connecting.
ERROR 2023-02-14T08:14:33.816 tokio-runtime-worker(ThreadId(5)) [1P:native-messaging/op-native-core-integration/src/lib.rs:481] Failed to accept new connection.: PipeAuthError(UnknownPeer(BinaryPermissions))

However, adding a shim script in the middle (run using system bash which is owned by root) works. This led me to creating this script in ~/.bin/op (~/.bin is on my path) for my test cases:
```

!/bin/bash

/usr/bin/op $@
``
I was usingpstree -aps $$in earlier versions of the script to look at the process call tree, but it really wasn't necessary as it appears only the one immediately before runningop` actually matters. With this, calling op directly from task, python and others just work. This is trivially bypassing the restriction on binary ownership which just seems to get in the way.

@Jack.P_1P Forgive my ignorance, you can tell me this is all kinds of awful and to knock it off, but would it be possible to share with us the security reasons for the binary ownership restriction? It would also be good for this to be documented somewhere.

@rsysring I saw you were trying to use pyenv. I am wondering if the shim process the pyenv and other tools like asdf use may be an issue also.