
1password
Wire 1Password CLI (`op`) into agent workflows so env vars, files, and templates load secrets without pasting them into chat or repos.
Overview
1password is an agent skill most often used in Build (also Ship, Operate) that teaches 1Password CLI (`op`) read, run, and inject workflows so solo builders never hardcode vault secrets.
Install
npx skills add https://github.com/steipete/clawdis --skill 1passwordWhat is this skill?
- Documents core `op` flows: sign-in, `op read` for vault items (password, OTP, SSH keys), and file export via `--out-file
- `op run` and `op inject` patterns for env vars and templated config without embedding secrets in code
- Covers account discovery with `op whoami` and `op account list`
- Summarizes desktop app integration prerequisites (subscription, OS shells, PolKit on Linux, Touch ID/Hello options)
- CLI-oriented examples suitable for copy into shell steps an agent executes
- 6 command areas documented: Sign in, Read, Run, Inject, Whoami / accounts, plus get-started OS/shell notes
Adoption & trust: 1.9k installs on skills.sh; 378k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need agents and scripts to use production-like secrets locally without copying passwords into `.env` files, prompts, or git.
Who is it for?
Indie builders on macOS, Windows, or Linux who already pay for 1Password and want Claude/Cursor to run vault-backed commands correctly.
Skip if: Teams that do not use 1Password, headless CI without approved `op` service accounts, or workflows that require storing secrets outside the vault.
When should I use this skill?
Agent tasks need 1Password CLI sign-in, vault reads, `op run`, or `op inject` for local or deploy configuration.
What do I get? / Deliverables
You get repeatable `op read`, `op run`, and `op inject` command patterns agents can execute against `op://` vault references with desktop integration enabled.
- Copy-ready `op` command snippets
- Env and template injection patterns using vault references
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Secret injection is most often needed while integrating services and local run scripts during the Build phase, though the same patterns recur when shipping configs and operating deployed apps. Integrations subphase is the canonical shelf for third-party credential tools that connect apps, CI, and agent-run commands to a vault.
Where it fits
Point a local API at `op read op://app-prod/db/password` instead of checking a plaintext DB password into git.
Generate release config from a template using `op inject` so staging URLs and keys stay in the vault.
Export an SSH key with `op read --out-file` for a one-off server fix without leaving keys in the repo.
How it compares
Vault-reference CLI cookbook for agents—not a generic `.env` generator or a secrets-scanning security audit skill.
Common Questions / FAQ
Who is 1password for?
Solo and indie developers who use 1Password and want coding agents to invoke the official `op` CLI for secrets instead of asking for raw credentials in chat.
When should I use 1password?
During Build when wiring third-party APIs and databases; during Ship when templating deploy configs; during Operate when rotating or re-reading vault items for runbooks—whenever SKILL-style tasks need `op read`, `op run`, or `op inject` examples.
Is 1password safe to install?
It documents shell commands that touch your vault; review the Security Audits panel on this Prism page and restrict agent permissions before allowing automated `op` sign-in or secret reads.
SKILL.md
READMESKILL.md - 1password
# op CLI examples (from op help) ## Sign in - `op signin` - `op signin --account <shorthand|signin-address|account-id|user-id>` ## Read - `op read op://app-prod/db/password` - `op read "op://app-prod/db/one-time password?attribute=otp"` - `op read "op://app-prod/ssh key/private key?ssh-format=openssh"` - `op read --out-file ./key.pem op://app-prod/server/ssh/key.pem` ## Run - `export DB_PASSWORD="op://app-prod/db/password"` - `op run --no-masking -- printenv DB_PASSWORD` - `op run --env-file="./.env" -- printenv DB_PASSWORD` ## Inject - `echo "db_password: {{ op://app-prod/db/password }}" | op inject` - `op inject -i config.yml.tpl -o config.yml` ## Whoami / accounts - `op whoami` - `op account list` # 1Password CLI get-started (summary) - Works on macOS, Windows, and Linux. - macOS/Linux shells: bash, zsh, sh, fish. - Windows shell: PowerShell. - Requires a 1Password subscription and the desktop app to use app integration. - macOS requirement: Big Sur 11.0.0 or later. - Linux app integration requires PolKit + an auth agent. - Install the CLI per the official doc for your OS. - Enable desktop app integration in the 1Password app: - Open and unlock the app, then select your account/collection. - macOS: Settings > Developer > Integrate with 1Password CLI (Touch ID optional). - Windows: turn on Windows Hello, then Settings > Developer > Integrate. - Linux: Settings > Security > Unlock using system authentication, then Settings > Developer > Integrate. - After integration, run any command to sign in (example in docs: `op vault list`). - If multiple accounts: use `op signin` to pick one, or `--account` / `OP_ACCOUNT`. - For non-integration auth, use `op account add`. --- name: 1password description: "Set up and use 1Password CLI for sign-in, desktop integration, and reading or injecting secrets." homepage: https://developer.1password.com/docs/cli/get-started/ metadata: { "openclaw": { "emoji": "🔐", "requires": { "bins": ["op"] }, "install": [ { "id": "brew", "kind": "brew", "formula": "1password-cli", "bins": ["op"], "label": "Install 1Password CLI (brew)", }, ], }, } --- # 1Password CLI Follow the official CLI get-started steps. Don't guess install commands. ## References - `references/get-started.md` (install + app integration + sign-in flow) - `references/cli-examples.md` (real `op` examples) ## Workflow 1. Check OS + shell. 2. Verify CLI present: `op --version`. 3. Confirm desktop app integration is enabled (per get-started) and the app is unlocked. 4. REQUIRED: create a fresh tmux session for all `op` commands (no direct `op` calls outside tmux). 5. Sign in / authorize inside tmux: `op signin` (expect app prompt). 6. Verify access inside tmux: `op whoami` (must succeed before any secret read). 7. If multiple accounts: use `--account` or `OP_ACCOUNT`. ## REQUIRED tmux session (tmux) The shell tool uses a fresh TTY per command. To avoid re-prompts and failures, always run `op` inside a dedicated tmux session with a fresh socket/session name. Example (see `tmux` skill for socket conventions, do not reuse old session names): ```bash SOCKET_DIR="${OPENCLAW_TMUX_SOCKET_DIR:-${TMPDIR:-/tmp}/openclaw-tmux-sockets}" mkdir -p "$SOCKET_DIR" SOCKET="$SOCKET_DIR/openclaw-op.sock" SESSION="op-auth-$(date +%Y%m%d-%H%M%S)" tmux -S "$SOCKET" new -d -s "$SESSION" -n shell tmux -S "$SOCKET" send-keys -t "$SESSION":0.0 -- "op signin --account my.1password.com" Enter tmux -S "$SOCKET" send-keys -t "$SESSION":0.0 -- "op whoami" Enter tmux -S "$SOCKET" send-keys -t "$SESSION":0.0 -- "op vault list" Enter tmux -S "$SOCKET" capture-pane -p -J -t "$SESSION":0.0 -S -200 tmux -S "$SOCKET" kill-session -t "$SESSION" ``` ## Guardrails - Never paste secrets into logs, chat, or code. - Prefer `op run` / `op inject` over writing secrets to disk. - If sign-in witho