This article follows the official documentation. We haven’t tested this tool for a hands-on review.
When you use a coding agent to run shell commands, those commands may need credentials to test a service or run a project locally. The 1Password command-line interface, op, lets a command retrieve credentials from your 1Password account when it runs. A secret reference points to a stored value, such as an API token, without containing the token itself.
If an agent can run shell commands, put secret references in a local environment file and use op run to start the command that needs them. op run replaces each reference with its stored value and passes that value to the command as an environment variable. The agent does not need the secret in its prompt or source files. See the official CLI documentation for current installation and command details.
Install and authenticate
Install 1Password CLI using the instructions for your operating system in the official documentation. Then check that your shell can find it:
op --version
For interactive development, sign in to the 1Password desktop app and enable its CLI integration. The CLI can then use the desktop app’s account session. For automation, use a service account, a separate identity for scripts or agents. It can access only the vaults granted to it. Store its token in the agent runner’s protected environment, not in the prompt or a checked-in file. 1Password describes service accounts and runtime secret access as options for developer and AI workflows.
You can check whether the CLI can access your account by running:
op vault list
This command contacts 1Password and lists vaults the signed-in account or service account can access. If the command fails, resolve authentication or vault permissions before asking an agent to use a secret.
Inject a secret for a local command
Suppose a local test script needs an API token. In a project-local .env file, put a secret reference instead of the token:
API_TOKEN=op://Development/ApiCredential/token
Development, ApiCredential, and token are illustrative names. Replace them with the vault, item, and field names that exist in your 1Password account. A field is the stored value you want to supply, such as a password or API token.
Run the local command with op run:
op run --env-file=.env -- sh -c 'test -n "$API_TOKEN" && printf "API_TOKEN is available\n"'
op run uses your 1Password account to replace the reference with the stored value, then starts the command with API_TOKEN in its environment. The shell prints only a fixed confirmation, not the token. The script and any child processes it starts can read the value, so avoid commands that print environment variables or write them to logs. op run contacts 1Password to get the value; the test command runs locally. This example reads a credential but does not change a remote service.
A realistic agent request is: “Run the local API configuration check with op run and the project’s .env file. Do not print the token or copy it into a file. Report whether the check passes.”
Keep secret values out of agent output
The CLI also supports commands that print item values directly. For example, op read returns the value of a secret reference. That can be useful for a person working in a terminal, but it puts the secret in command output that an agent may read, summarize, or log. Prefer op run when a program needs the value.
For commands that return item or vault details, the CLI documentation describes JSON output formatting. JSON is useful when a script needs structured metadata, but a JSON response that includes secret fields still contains the secrets. Avoid sending that output to the agent when it only needs to know whether a command succeeded.
op run also does not prevent an agent with shell access from deliberately inspecting the environment of a command it launches. It controls how a command receives secrets; it does not make those values invisible to the account or code running with that access. Give an agent only the credentials and vault permissions its task needs.
Where this approach fits
Use op run when a local command or test needs 1Password credentials and the agent can run the CLI. The project’s configuration file contains references instead of the credentials themselves. The command receives the credentials as environment variables, which many tools already know how to read.
The CLI still depends on 1Password authentication and the account’s vault permissions. For automated work, a service account avoids tying access to a person’s desktop session, but its token itself must remain protected. If the task requires the agent to create or change resources in an external service, separate that write from credential setup and ask the agent to confirm the exact change before it runs.