Use the 1Password CLI (op) to retrieve secrets directly in your terminal with op item get "API Key" --field password, eliminating hardcoded credentials from config files and environment variables. Install it via brew install --cask 1password-cli on macOS, authenticate with op signin, and inject secrets into scripts, CI/CD pipelines, or shell aliases. This guide walks through setup, authentication, vault management, and scripting patterns for secure secrets management.

What is the 1Password CLI?

The 1Password CLI (op) is a command-line tool that allows you to interact with your 1Password vault programmatically. Rather than manually copying passwords or API keys from the 1Password app, you can retrieve secrets directly within your terminal. This approach eliminates clipboard history risks and ensures that sensitive credentials never linger in your system memory longer than necessary.

The CLI supports various authentication methods, including biometric authentication via Touch ID or Windows Hello, as well as session-based authentication for automated workflows. This flexibility makes it suitable for both interactive development sessions and CI/CD environments.

Installing the 1Password CLI

On macOS, the simplest installation method uses Homebrew:

brew install --cask 1password-cli

For Linux or Windows Subsystem for Linux (WSL), download the appropriate binary from the official 1Password GitHub repository. After installation, verify the setup by checking the version:

op --version

Authenticating with 1Password

Before retrieving secrets, you must authenticate with your 1Password account. For interactive use, run:

op signin

This command opens your default browser where you complete the authentication process. On macOS with Touch ID configured, subsequent commands can use biometric authentication automatically, removing the need to re-enter your master password repeatedly.

For automated workflows, you can create a service account or use the OP_SESSION environment variable to maintain an authenticated session across multiple commands:

eval $(op signin --account myteam)

This command exports the session credentials to your shell environment, valid for a configurable duration.

Retrieving Secrets

Once authenticated, retrieving a secret is straightforward. The basic syntax uses the item name and field you want to access:

op item get "API Key" --field password

1Password stores various item types, each with different fields. For a login item, common fields include username, password, and notes. For custom fields, specify the field name directly:

op item get "Production Database" --field "connection-string"

You can also retrieve secrets by their UUID if you know it:

op item get u7w8x9y2z --field password

Integrating with Environment Variables

One of the most practical applications of the 1Password CLI is populating environment variables for your applications. This approach keeps credentials out of configuration files while making them available at runtime.

Single-Command Usage

For one-off commands, you can inject the secret directly:

DATABASE_PASSWORD=$(op item get "Database Password" --field password) your_application

This pattern works well for scripts that need temporary access to a credential without storing it persistently.

Shell Aliases for Frequent Access

If you frequently access certain secrets, consider creating shell aliases:

alias prod-db='op item get "Production DB" --field password'

Add this to your shell configuration file (.bashrc or .zshrc) for persistent access.

Working with Multiple Vaults

Larger organizations often use multiple vaults to separate secrets by environment or team. By default, op queries your personal vault. To access a specific vault, use the --vault flag:

op item get "Shared API Key" --vault "Engineering Team" --field password

Listing available vaults helps you understand your access:

op vault list

This command displays all vaults your account can access, including shared team vaults.

Scripting with 1Password CLI

For more complex automation, shell scripts provide greater control. Here’s an example that retrieves multiple secrets and exports them for a database migration:

#!/bin/bash

# Authenticate and export session
eval $(op signin --account myteam)

# Retrieve secrets
DB_USER=$(op item get "Migration User" --field username)
DB_PASS=$(op item get "Migration User" --field password)
DB_HOST=$(op item get "Migration User" --field "host")

# Run migration
PGPASSWORD="$DB_PASS" psql -h "$DB_HOST" -U "$DB_USER" -d myapp -f migration.sql

# Clear sensitive variables
unset DB_PASS

This script demonstrates several best practices: authenticating once at the start, retrieving only the necessary fields, running the task, and cleaning up sensitive variables afterward.

Security Considerations

While the 1Password CLI significantly improves security compared to hardcoded credentials, following best practices maximizes its effectiveness:

Session management is critical. The default session duration is 30 minutes, but you can adjust this based on your workflow. For long-running CI/CD jobs, ensure the session remains active throughout the pipeline.

Audit logging is built into 1Password Business accounts. Review access logs regularly to identify unusual patterns, such as secrets being retrieved at unexpected times or from unfamiliar locations.

Least privilege access applies to vault permissions. Grant team members access only to the vaults and specific items they need. Avoid sharing vault passwords broadly; instead, use item-level sharing where possible.

Environment variable exposure can leak secrets inadvertently. Shell history and process environment displays may expose credentials. Use tools like dotenv to load secrets from files that are explicitly excluded from version control, or use container orchestration secrets management for larger deployments.

Comparing with Alternative Approaches

Other secret management solutions exist, including HashiCorp Vault, AWS Secrets Manager, and GitHub Secrets. The 1Password CLI appeals to teams already using 1Password for password management, providing a consistent experience across personal and work contexts. The learning curve is minimal for those familiar with the 1Password ecosystem, and the CLI integrates with the same vault used for everyday password management.

For teams requiring advanced features like secret rotation policies or fine-grained access controls, dedicated secrets management products may offer additional capabilities. However, for many development workflows, the 1Password CLI provides sufficient functionality with excellent usability.

Advanced: Using Templates

1Password supports templates for standard item structures. If your team consistently uses certain field arrangements—perhaps a database item always includes host, port, username, and password—create a template to ensure consistency:

op template create "Database Credentials" --fields "host,port,username,password"

This reduces errors and speeds up secret creation across your team.

Getting Started

Begin by installing the CLI and authenticating with your account. Start with a simple retrieval to understand the authentication flow, then progressively integrate secrets into your development workflow. The incremental approach helps identify any permission issues or workflow adjustments needed before deploying to production environments.

The 1Password CLI turns secret management into a secure, scriptable workflow. Treating credentials as programmable data rather than static text makes your systems more secure by design.

Built by theluckystrike — More at zovo.one