| name | one-password |
| description | 1Password/op: scoped service-account reads first, targeted secret read/store/inject, interactive desktop sign-in fallback. |
| role | tool-workflow |
| metadata | {"clawdbot":{"emoji":"🔐","requires":{"bins":["op"]},"install":[{"id":"brew","kind":"brew","formula":"1password-cli","bins":["op"],"label":"Install 1Password CLI (brew)"}]}} |
1Password CLI
Generic safe op workflow: pick the access path, run targeted reads/writes, verify shape only. Exact account, vault, item, and field mappings belong to the owning capability, never here.
No-args or unclear request: start at Workflow step 1 — name the owning capability and its declared mapping.
Access Paths
- Scoped service-account read (preferred, unattended). Non-interactive
op with a token scoped to the vault the owning capability declares. Runs as one plain command with an explicit --vault; never routes through tmux or a persistent PTY.
- Interactive desktop sign-in (fallback, user-present). Requires app integration and
op signin; ask before falling back. Run the whole interactive task in one persistent shell session (tmux or a persistent agent PTY) because sign-in state does not survive fresh shells. Interactive sessions preserve sign-in only; they never feed values into unattended flows.
Token custody
- Inject a service-account token per command from a managed source (keychain or a 1Password-backed wrapper). Never park it in
~/.profile, shell rc, .env files, tmux/PTY environment, or exported ambient env.
- Browser-login secrets and the Browser Automation token are out of scope:
browser-use owns that custody and delivery end-to-end (skills/browser-use/src/browser-use-op.ts, handle-only env spec; typed repair continuations discoverable through the browser-use auth command family). Never fetch browser-login secrets with this skill.
- Browser sessions receive no vault or item administration. Keep explicit vault listing and item create/update requests in this workflow; never grant those operations through a Browser Use credential transaction.
Workflow
- Get the owning capability's declared mapping: account, vault, item, field, expected shape. Missing mapping: stop and ask; never enumerate to discover.
- Choose the access path above.
- Service-account read: one non-interactive command run through the managed token source, e.g.
<token-wrapper> op item get "<item>" --vault "<vault>" --format json, where <token-wrapper> injects OP_SERVICE_ACCOUNT_TOKEN for that command only — never a bare op call against ambient auth. Extract the exact labeled field (references/cli-examples.md).
- Interactive fallback:
op signin then op whoami in the persistent session; keep every follow-up command, retry, and verification in that same session — never start a second one.
- Verify shape only: length, expected prefix, newline count. Never print values.
Guardrails
- Never print secret values to logs, chat, or code; shape-only checks.
- Never enumerate accounts, vaults, or items to discover candidates. On an explicit user ask, search metadata only within the token-scoped vault (
references/cli-examples.md).
- Prefer
op run / op inject over writing secrets to disk; any materialized output is a scoped, non-canonical compatibility artifact (CONTEXT.md: Materialized secret adapter).
- Multiple accounts: pass
--account explicitly; confirm names with op account list (metadata-only) when routing is unclear.
op --field / --fields label= can return the wrong concealed field on items with duplicate or legacy fields; read the item as JSON and extract the exact label.
References
- Official docs: https://developer.1password.com/docs/cli/get-started/
references/get-started.md — install, app integration, sign-in.references/cli-examples.md — safe create/edit, shape-only field reads, vault-scoped metadata search.- Vocabulary:
CONTEXT.md.
- Unattended-vs-interactive semantics owner:
docs/plans/2026-07-21-003-feat-browser-use-cross-adapter-authentication-plan.md (R7, R16); docs/adr/0028-auth-u3-splits-pure-contract-from-signed-native-capability.md.
