About this skill

Problem

1Password CLI is useful for reading secrets and running credentialed commands in a terminal, but it is not automatically stable in agent, CI, or multi-tool workflows. Common pain points include each command starting a fresh shell, login state not persisting, repeated app authorization prompts, secrets leaking into temp files, logs, or chat context, and account mismatches when multiple 1Password accounts are present. This skill turns ad hoc op usage into a checkable, recoverable, low-leak operations workflow.

How It Works

Environment checks: confirm OS, shell, CLI availability, desktop app integration, and unlock state according to official get-started expectations.
tmux session: run every op command in a fresh, isolated tmux session. Because a shell tool may open a new TTY per command, a dedicated session reduces repeated prompts and sign-in failures.
Sign-in and verification: authorize inside tmux and verify current access with op whoami; use --account or OP_ACCOUNT for multi-account setups.
Secret injection: prefer op run or op inject to pass credentials to commands instead of writing secrets to disk, logs, or code.
Failure recovery: if a command reports an unsigned-in or mismatched account, return to the tmux session to sign in and authorize again rather than retrying across multiple shells.

Boundaries

This fits local ops, script assistance, and agent tool calls that need secure 1Password CLI access. If tmux is unavailable, stop and confirm an alternative execution environment before running op outside the session constraint. It also discourages guessing install commands, pasting secrets, or storing credentials in temp files; app-integration-free sign-in should follow official paths such as op account add.