Using 1Password CLI Safely in WSL

When a development command inside WSL needs a value from 1Password, the first question is whether to call the Windows op.exe or use the Linux op. Leaving that choice implicit adds boundaries around authentication, paths, and standard input and output.

This note assumes that Linux development tools run inside WSL and examines the Linux 1Password CLI setup, the difference between op run and op read, and reading an OTP attribute. The CLI reduces some exposure paths; it does not make secrets safe automatically.

Match the CLI to the operating environment

The 1Password CLI installation guide separates installation instructions for Windows and Linux. When a WSL process needs the value, this is a useful starting boundary:

Where the command runs	CLI to start with	What to verify
PowerShell or a Windows application	Windows version	Windows PATH and authentication
Bash, Zsh, or development tools inside WSL	Linux version	WSL PATH and authentication

Calling Windows op.exe from WSL is not automatically unsafe. It does, however, bridge a Windows session into a Linux process and adds more behavior to explain and reproduce. Start with the CLI on the same side as the process, and consider a cross-boundary setup only when it is needed.

Check only non-secret state after installation

After installation, check the version and authenticated identity without printing a secret value.

op --version
op whoami

If op whoami fails, copying credential files between Windows and WSL is not the first remedy. Desktop-app integration can depend on the environment, so check the official Linux authentication procedure. For automation, consider a service account limited to the required use instead of reusing a personal session.

Use op run for a development process

The guide to using secrets in scripts describes resolving secret references into environment variables only while a command runs. Keep references, not values, in the template.

DATABASE_URL=op://Development/App Database/url
API_TOKEN=op://Development/App API/token

Resolve them at execution time:

op run --env-file=.env.tpl -- pnpm dev

This avoids generating a plaintext .env in the working tree for ordinary development. It does not protect against a child process that logs environment variables. Shell tracing such as set -x, debug logs, and exception reports are part of the same review.

op run narrows where and how long the value exists; it does not remove every leak path.

Use op read for one value

When a command accepts standard input, op read is easier to keep out of process arguments and shell history.

op read "op://Development/App API/token" | some-command --token-stdin

If the command accepts only --token VALUE, the value may appear in a process listing, shell history, or debug output. Check whether the receiving command supports standard input, an environment variable, or a credential helper.

Separate an OTP URI from the current code

An otpauth:// URI contains the shared seed used to generate one-time passwords. It is a long-lived secret, even though the six-digit code changes frequently. Do not paste the URI into logs, issues, chats, or screen shares.

If only the current code is needed, read the OTP attribute described in the op read reference.

op read "op://Private/Service Login/one-time password?attribute=otp"

Use the vault, item, and field names that exist in the account. Export an otpauth:// URI only for a defined task such as authenticator migration, with a defined destination for the resulting secret.

Diagnose failures without printing the value

When authentication or secret resolution fails, inspect state rather than the secret itself:

• Whether the command uses the Windows or Linux op
• Whether op whoami shows the expected account and vault access
• Whether the vault, item, and field in the reference are correct
• Whether set -x and debug logging are disabled
• Whether a child process records environment variables

Avoid echo $SECRET, env, and command lines that interpolate the value, even as a quick check. If a value may already have reached a log or history, rotate the secret first; deleting the visible line is not enough.

Boundary of this setup

For Linux processes inside WSL, the Linux CLI, op run, and standard input give the access path a clear shape. If both Windows applications and WSL processes use the same account, authenticate and reason about each process boundary separately.

The purpose of 1Password CLI is not to make secrets easy to print. It is to deliver each value to the required process for the required time through an auditable path, while reducing the opportunities to display or persist it.