one-password

name	one-password
description	Fetch secrets and env vars from 1Password via the `op` CLI. Primary path is a non-interactive service-account token (no prompts); Touch ID is the fallback. Use whenever a command needs an API key, token, password, or `.env` value — read it from 1Password instead of hardcoding, printing, or asking the user to paste it. Triggers: op, op read, op run, op inject, op://, 1Password, fetch a secret, get an API key, inject env vars.
metadata	{"requires":{"bins":["op"]},"install":[{"id":"brew","kind":"brew","formula":"1password-cli","bins":["op"],"label":"Install 1Password CLI (brew)"}]}

1Password CLI (op)

Fetch secrets and environment variables from 1Password so commands run with real credentials without hardcoding them, printing them, or asking the user to paste.

Auth model (Ossian's Mac)

Primary — service account (no human in the loop). A service-account token is exported as OP_SERVICE_ACCOUNT_TOKEN in ~/.zshenv, so every shell (including non-interactive agent shells) can run op with no Touch ID prompt. The token is scoped to the Development vault only — that is the blast radius if it leaks. It currently has read_items and write_items so agents can both retrieve and maintain repo/app secrets without a manual 1Password handoff.

• Default account: my.1password.com.
• The service account can read and write items in the Development vault. Secrets an agent needs non-interactively must live there. It cannot see Personal, H&M, or Rebtech.
• Service-account reads need an explicit vault: the vault is in the op:// ref for op read; for op item get/op item list pass --vault Development.
• Service-account writes should stay vault-scoped and intentional: use existing app/repo items when possible, add clear repo tags/sections, and inspect the target item structure before broad rewrites.

Fallback — Touch ID (interactive). To reach a vault outside the service account's scope (Personal, H&M, Rebtech), unset the token for that one command so op uses desktop app integration and prompts Touch ID:

env -u OP_SERVICE_ACCOUNT_TOKEN op read "op://Personal/SomeItem/field"

This requires the user present to approve — use it only when the secret genuinely isn't (and can't be) in Development.

Core operations

Reference syntax is op://<vault>/<item>/<field>. For non-interactive use the vault is almost always Development.

Read one secret

op read "op://Development/OpenAI/api_key"

Inline for a single command so the value never lands in a variable or log:

OPENAI_API_KEY="$(op read 'op://Development/OpenAI/api_key')" some-tool --run

Run a command with secrets injected (preferred for many vars)

Keep a .env of op:// references (safe to commit — they're pointers, not values):

# .env
OPENAI_API_KEY=op://Development/OpenAI/api_key
DATABASE_URL=op://Development/AppDB/connection_string

op run --env-file=.env -- npm run dev

op resolves every op:// ref into the child process's environment and nowhere else.

Inject secrets into a config template

echo "db_password: {{ op://Development/AppDB/password }}" | op inject
op inject -i config.tpl.yml -o config.yml      # render a whole file

Special field attributes

op read "op://Development/SomeItem/one-time password?attribute=otp"   # TOTP code
op read "op://Development/server/private key?ssh-format=openssh"      # SSH key
op read --out-file ./key.pem "op://Development/server/ssh/key.pem"    # write to file

Adding a new secret for agents to use

Put it in the Development vault. Prefer the service account for agent-managed items and use repo-specific item names, tags, and sections so secrets do not get mixed across projects:

op item create --vault Development \
  --category "API Credential" --title "Some Service" \
  --tags "repo:some-repo,project:some-project" \
  "api_key[password]=…"

Then agents read it non-interactively via op read "op://Development/Some Service/api_key".

For sensitive values, prefer JSON templates or op run/op inject over command-line assignment statements so secrets do not appear in process arguments. If you need a human-owned vault outside Development, unset the service account token and use the Touch ID fallback.

Finding the right reference

Prefer asking the user for the exact op:// path, or copy it from the app (right-click a field → "Copy Secret Reference"). If you must discover it, stay metadata-only and vault-scoped — list titles, never field values:

op item list --vault Development --format json        # titles/ids/categories only
op item get "OpenAI" --vault Development --format json # inspect field LABELS, not values

Do not enumerate other vaults by default. Search only when the user asks.

Guardrails

• Never print or log secret values or the token. No echo $TOKEN, no set -x around op, no cat of rendered output. To sanity-check a read, print shape only (length, prefix), never the value.
• Prefer op run / op inject over writing secrets to disk. If a file is unavoidable (--out-file), delete it as soon as the command that needs it is done.
• No broad enumeration. Don't run env, export -p, or list every vault to "find" a secret — query the exact item/field in Development.
• Don't widen the service account's scope or reach into Personal casually. Use the Touch ID fallback deliberately and only when needed.
• If op read returns the wrong field (items with duplicate/legacy fields), read the item as JSON and pick the exact label rather than guessing.

Operations

• Token lives in ~/.zshenv (OP_SERVICE_ACCOUNT_TOKEN). It is scoped to Development with read_items and write_items.
• Rate limits: op service-account ratelimit shows usage if reads start failing.
• Rotate/replace: create a new one with op service-account create <name> --vault Development:read_items,write_items --raw, update ~/.zshenv. The old token keeps working until deleted in the 1Password web UI.

Service Account Credential

The service-account token itself is stored in op://Development/1Password Service Account — mac-mini-agents/credential. That item should be tagged tool:1password, service-account, mac-mini-agents, vault:development, and permission:read-write. If the token is rotated, update both that 1Password item and ~/.zshenv, then verify op item edit works without unsetting OP_SERVICE_ACCOUNT_TOKEN.

Service-specific credentials

Keep service-specific auth (which item, which fields) in the owning skill or the project's .env of op:// refs. This skill owns only the generic rules: service-account-first, targeted reads, no enumeration, never print values.