1Password Skill for Hermes Agent: Read and Inject Secrets

The 1Password skill lets a Hermes Agent pull secrets from a 1Password vault instead of reading them from plaintext environment variables or files on disk. It wraps the op CLI so the agent can sign in, resolve op:// references, render templates, and run commands with secrets injected at execution time. Reach for it when you want credentials to stay in 1Password and only appear in the agent's process environment for the duration of a command.

What it does

The skill covers the full lifecycle of using 1Password from an agent: installing and configuring the CLI, authenticating, reading individual secret references, injecting secrets into config templates, and running commands with secret environment variables. It also documents a tmux-based execution pattern for the desktop app flow, because Hermes terminal calls are non-interactive by default and can lose authentication context between calls.

In practice, this means the agent can resolve a reference like op://app-prod/db/password at the moment it needs it, rather than storing the password in a file the agent might later read back or log.

Before you start

The source lists these requirements:

• A 1Password account.
• The 1Password CLI (op) installed.
• One of three authentication paths: desktop app integration, a service account token (OP_SERVICE_ACCOUNT_TOKEN), or a Connect server.
• tmux available for stable authenticated sessions during Hermes terminal calls. This applies to the desktop app flow only.

If you are running headless or in CI, the desktop app integration will not be available, so plan on the service account token path instead.

Authentication methods

Service account (recommended for Hermes)

Set OP_SERVICE_ACCOUNT_TOKEN in ${HERMES_HOME:-~/.hermes}/.env. The skill will prompt for this on first load. No desktop app is needed, and the token supports op read, op inject, and op run.

export OP_SERVICE_ACCOUNT_TOKEN="your-token-here"
op whoami  # verify — should show Type: SERVICE_ACCOUNT

The op whoami call is a sanity check: if the token is valid and scoped correctly, the account type reported should be SERVICE_ACCOUNT.

Desktop app integration (interactive)

1. Enable integration in the 1Password desktop app: Settings → Developer → Integrate with 1Password CLI.
2. Make sure the app is unlocked.
3. Run op signin and approve the biometric prompt.

This path is interactive by nature, which is why the tmux pattern below exists.

Connect server (self-hosted)

export OP_CONNECT_HOST="http://localhost:8080"
export OP_CONNECT_TOKEN="your-connect-token"

Use this when you already run a 1Password Connect server and want the agent to talk to it directly.

Setup

1. Install the CLI:

# macOS
brew install 1password-cli

# Linux (official package/install docs)
# See references/get-started.md for distro-specific links.

# Windows (winget)
winget install AgileBits.1Password.CLI

2. Verify the install:

op --version

3. Pick one of the authentication methods above and configure it.

Hermes execution pattern (desktop app flow)

Hermes terminal commands are non-interactive by default and can lose auth context between calls. For reliable op use with desktop app integration, run sign-in and secret operations inside a dedicated tmux session.

This is not needed when using OP_SERVICE_ACCOUNT_TOKEN, because the token persists across terminal calls automatically.

SOCKET_DIR="${TMPDIR:-${HERMES_HOME:-$HOME/.hermes}/cache/scratch}/hermes-tmux-sockets"
mkdir -p "$SOCKET_DIR"
SOCKET="$SOCKET_DIR/hermes-op.sock"
SESSION="op-auth-$(date +%Y%m%d-%H%M%S)"

tmux -S "$SOCKET" new -d -s "$SESSION" -n shell

# Sign in (approve in desktop app when prompted)
tmux -S "$SOCKET" send-keys -t "$SESSION":0.0 -- "eval \"\$(op signin --account my.1password.com)\"" Enter

# Verify auth
tmux -S "$SOCKET" send-keys -t "$SESSION":0.0 -- "op whoami" Enter

# Example read
tmux -S "$SOCKET" send-keys -t "$SESSION":0.0 -- "op read 'op://Private/Npmjs/one-time password?attribute=otp'" Enter

# Capture output when needed
tmux -S "$SOCKET" capture-pane -p -J -t "$SESSION":0.0 -S -200

# Cleanup
tmux -S "$SOCKET" kill-session -t "$SESSION"

The pattern is: create a private socket directory, start a detached tmux session on that socket, send the sign-in command, verify with op whoami, then send whatever op commands you need. capture-pane pulls the visible output back so the agent can read it. Kill the session when you are done so the authenticated shell does not linger.

Common operations

Read a secret

op read "op://app-prod/db/password"

Resolves a single field from a single item. This is the simplest way to get one value, but it puts the secret in the agent's output stream, so treat the result carefully.

Get an OTP

op read "op://app-prod/npm/one-time password?attribute=otp"

One-time passwords are a field attribute rather than a plain field, so the reference uses the ?attribute=otp query.

Inject into a template

echo "db_password: {{ op://app-prod/db/password }}" | op inject

op inject reads a template on stdin and substitutes each {{ op://... }} placeholder with the resolved value. This is the right tool when you need to produce a config file that contains secrets, without ever writing the secret into the template itself.

Run a command with a secret env var

export DB_PASSWORD="op://app-prod/db/password"  # example op:// reference, resolved by `op run`
op run -- sh -c '[ -n "$DB_PASSWORD" ] && echo "DB_PASSWORD is set" || echo "DB_PASSWORD missing"'

op run resolves any environment variable whose value looks like an op:// reference, then executes the command with the resolved values in place. The secret exists only for the lifetime of that command.

When not to use it

If the desktop app integration is unavailable, for example on a headless server or in CI, do not try to force the interactive flow. Use the service account token path instead. The source also implies a preference against writing secrets to files: prefer op run and op inject over materialising secrets on disk.

Limits and gotchas

• Never print raw secrets back to the user unless they explicitly ask for the value.
• Prefer op run and op inject over writing secrets into files.
• If a command fails with "account is not signed in", run op signin again in the same tmux session.
• For non-interactive use, authenticate with OP_SERVICE_ACCOUNT_TOKEN and avoid interactive op signin. Service accounts require CLI v2.18.0+.

Related references

The skill ships with references/get-started.md and references/cli-examples.md. Upstream documentation lives at https://developer.1password.com/docs/cli/ and https://developer.1password.com/docs/service-accounts/.