I tried op.exe with "run", but then it couldn't find the command I wanted to wrap, it was looking for the command in the Windows environment rather than WSL.

Technically, you can do that via zshrc/bashrc file by aliasing op to op.exe
alias op='op.exe' and restarting terminal session or using source to load new changes. Basically same thing we do to ssh to enable git with 1password under WSL.

Then you have two options you can access you 1password valut for example or do op signin and then access your stuff. Both of which will ask you (Windows Hello/Pin/Local Password) like it normally does.

WSL should know windows PATH, but by default Ubuntu has that enabled in WSL settings.

+1

+1

One thing to be aware of if invoking the Windows op.exe from WSL: environment variables are not passed by default to Windows processes spawned from WSL (& vice versa). Some tools that integrate with the 1Password CLI rely on passing environment variables, e.g. OP_FORMAT, which will result in issues if the tool is run from WSL.

In particular the 1Password Terraform provider (in one configuration) wraps the CLI, and relies on environment variables like OP_FORMAT=json to configure it to give output that it can parse correctly. When running Terraform in WSL against a Windows CLI, these environment variables don't get passed to the spawned process, which means amongst other things that the CLI output is not JSON as the Terraform provider is expecting which causes things to fail with an error message like: "Unable to read vault, got error: invalid character 'I' looking for beginning of value".

Once I'd realised the cause of the issue, my workaround was to wrap the op.exe binary with a shell script that directs WSL to forward all OP_* environment variables to Windows using the WSLENV environment variable. My op script sits next to op.exe and looks like:

```bash

!/usr/bin/env bash

mapfile -d '' op_env_vars < <(env -0 | grep -z ^OP_ | cut -z -d= -f1)
export WSLENV="${WSLENV:-}:$(IFS=:; echo "${op_env_vars

This solved my issue and I wanted to share in case anyone else is in the same situation, and to ask that this use case is considered if/when an official solution is implemented or documented!

+1 from me as well!
Sure, the alias works, but it always feels better to have an "official" way.

Hi :) I'm struggling with this a bit at the moment.

One thing that might help in the interim is even a teency bit of documentation saying "Just use the Windows op.exe command from WSL2. You will need to restart your WSL2 session for the new winget installed package path to be added to %PATH% at the system level" or similar.

Totally love the CLI and especially the new query syntax! SO much easier than having to reference Item IDs like we did in the old days!

+1

I have a solution for Windows 11 WSL2!

Please let other people know if this solution does not work for you.
1. Open CMD and "winget install 1password-cli" or go to 1password docs and figure out how to install the WINDOWS version of 1password cli.
2. If you installed with winget, you should be able to navigate to "C:\Users<username>\AppData\Local\Microsoft\WinGet\Packages<1password_cli_package_id>\op.exe"
3. if you did not use winget, navigate to the executable of the cli program
4. add this to your ~/.bashrc file in wsl:
alias op="/mnt/c/Users/........./op.exe"

Magic!

Definitely a +1