Last updated: March 15, 2026

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.

This command opens your default browser where you complete the authentication process.

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.

Prerequisites

Before you begin, make sure you have the following ready:

Step 1 - Install 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

Step 2 - Authenticate 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.

Step 3 - Retrieve 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

Step 4 - Integrate 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.

Step 5 - Work 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.

Step 6 - Script 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 environment, 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.

Advanced Usage - CI/CD Integration

For automated workflows, the CLI shines in CI/CD pipelines. Here’s how to integrate securely:

GitHub Actions integration:

name: Deploy with 1Password Secrets

on: [push]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Load 1Password secrets
        env:
          OP_SERVICE_ACCOUNT_TOKEN: ${{ secrets.OP_SERVICE_ACCOUNT_TOKEN }}
        run: |
          # Authenticate with 1Password service account
          op account add \
            --address my-team.1password.com \
            --email service@company.com \
            --signin

          # Export secrets for use in subsequent steps
          echo "DB_PASSWORD=$(op item get Database --field password)" >> $GITHUB_ENV
          echo "API_KEY=$(op item get ApiKey --field value)" >> $GITHUB_ENV

      - name: Run deployment
        run: ./deploy.sh
        env:
          DATABASE_PASSWORD: ${{ env.DB_PASSWORD }}
          SERVICE_API_KEY: ${{ env.API_KEY }}

GitLab CI integration:

deploy:
  stage: deploy
  image: ubuntu:latest
  script:
    # Install 1Password CLI
    - curl -sS https://downloads.1password.com/linux/keys/1password.asc | apt-key add -
    - apt-get update && apt-get install -y 1password-cli

    # Authenticate
    - eval $(op signin --account $OP_TEAM --email $OP_EMAIL)

    # Retrieve and use secrets
    - export DB_PASSWORD=$(op item get "Production Database" --field password)
    - export API_KEY=$(op item get "API Keys" --field service-key)

    # Run deployment
    - ./scripts/deploy.sh
  environment:
    name: production
  only:
    - main

Docker container approach:

FROM ubuntu:22.04

Install 1Password CLI
RUN apt-get update && apt-get install -y \
    curl \
    jq \
    && curl -sS https://downloads.1password.com/linux/keys/1password.asc | apt-key add - \
    && apt-get install -y 1password-cli

Copy deployment scripts
COPY ./scripts /app/scripts
WORKDIR /app

Runtime - Pass OP_SERVICE_ACCOUNT_TOKEN as environment variable
ENTRYPOINT ["/app/scripts/entrypoint.sh"]

Docker entrypoint script:

#!/bin/bash
entrypoint.sh - Authenticate and run deployment

set -e

Verify service account token exists
if [ -z "$OP_SERVICE_ACCOUNT_TOKEN" ]; then
    echo "ERROR: OP_SERVICE_ACCOUNT_TOKEN not set"
    exit 1
fi

Authenticate (service account uses token directly)
op account add \
    --address my-team.1password.com \
    --email deployment@company.com \
    --signin

Export secrets for application
export DATABASE_URL=$(op item get "Database Connection" --field url)
export API_SECRET=$(op item get "API Credentials" --field secret)

Run the actual deployment
exec "$@"

Audit and Compliance

Organizations using the 1Password CLI should implement audit controls:

Audit logging setup:

#!/bin/bash
Monitor 1Password CLI usage for audit trails

1Password Business accounts log all access
Configure audit exporting:

Export activity logs weekly
op activity list --days 7 > /secure/logs/1password-activity-$(date +%Y%m%d).json

Monitor for suspicious access patterns
grep -i "unauthorized\|failed\|error" /secure/logs/1password-activity-*.json

Alert on access from unexpected locations
op activity list --days 1 | jq '.[] | select(.location != "Expected-Office-IP")'

Compliance checklist:

1Password CLI Audit Checklist:

 Service accounts created for CI/CD (not using personal accounts)
 Service account tokens rotated quarterly
 Access logs exported and archived monthly
 Unauthorized access attempts reviewed weekly
 Vaults with sensitive secrets limited to 2-3 team members
 Screen sharing and clipboard access restricted during demonstrations
 Session timeouts configured (default 30 min is reasonable)
 Device approval required for new CLI sessions (if available)
 Master password changed after team member departures

Troubleshooting Common Issues

Issue - “op: command not found”

Installation path issue
which op  # Should return /usr/local/bin/op or similar

Add to PATH if not found
export PATH="/usr/local/bin:$PATH"

Verify installation
op --version

Issue - Session expires during long scripts

Extend session timeout
eval $(op signin --account myteam --cache)

For long-running processes, re-authenticate periodically
op item get "Secret Name" --field value || {
    eval $(op signin --account myteam)
    op item get "Secret Name" --field value
}

Issue - “Invalid master password”

Biometric authentication failed
op signin --account myteam

Explicitly provide password
OP_MASTER_PASSWORD="your-password" op item get "Secret" --field value

Or use session-based auth instead
eval $(op signin --account myteam)

Issue - “Access denied to vault”

Your account lacks permissions
Check available vaults:
op vault list

If vault not listed, request access from vault owner
Then specify the exact vault name:
op item get "ItemName" --vault "Vault Name" --field password

Performance Optimization

For scripts making many CLI calls:

#!/bin/bash
Retrieve multiple secrets efficiently

BAD - New authentication per call (slow)
op item get "Secret1" --field password
op item get "Secret2" --field password
op item get "Secret3" --field password

GOOD - Authenticate once, reuse session
eval $(op signin --account myteam)

SECRET1=$(op item get "Secret1" --field password)
SECRET2=$(op item get "Secret2" --field password)
SECRET3=$(op item get "Secret3" --field password)

BETTER - Batch retrieve from same item
SECRETS=$(op item get "AllSecrets")
DB_HOST=$(echo $SECRETS | jq -r '.fields[] | select(.label=="db-host") | .value')
DB_USER=$(echo $SECRETS | jq -r '.fields[] | select(.label=="db-user") | .value')
DB_PASS=$(echo $SECRETS | jq -r '.fields[] | select(.label=="db-pass") | .value')

Migrating from .env Files

If you’re transitioning from .env files:

#!/bin/bash
Migration script - .env to 1Password

Read existing .env file
while IFS='=' read -r key value; do
    if [ -n "$key" ] && [[ ! "$key" =~ ^#.* ]]; then
        # Create item in 1Password for each variable
        op item create --category password \
            --title "$key" \
            --generate-password=24 \
            value="$value"

        echo "Migrated: $key"
    fi
done < .env

Delete original .env (securely)
shred -vfz -n 3 .env
echo ".env file securely deleted"

Frequently Asked Questions

How long does it take to complete this setup?

For a straightforward setup, expect 30 minutes to 2 hours depending on your familiarity with the tools involved. Complex configurations with custom requirements may take longer. Having your credentials and environment ready before starting saves significant time.

What are the most common mistakes to avoid?

The most frequent issues are skipping prerequisite steps, using outdated package versions, and not reading error messages carefully. Follow the steps in order, verify each one works before moving on, and check the official documentation if something behaves unexpectedly.

Do I need prior experience to follow this guide?

Basic familiarity with the relevant tools and command line is helpful but not strictly required. Each step is explained with context. If you get stuck, the official documentation for each tool covers fundamentals that may fill in knowledge gaps.

Is this approach secure enough for production?

The patterns shown here follow standard practices, but production deployments need additional hardening. Add rate limiting, input validation, proper secret management, and monitoring before going live. Consider a security review if your application handles sensitive user data.

Where can I get help if I run into issues?

Start with the official documentation for each tool mentioned. Stack Overflow and GitHub Issues are good next steps for specific error messages. Community forums and Discord servers for the relevant tools often have active members who can help with setup problems.

Related Articles

Built by theluckystrike. More at zovo.one ```

Related Reading

Built by theluckystrike. More at zovo.one