1password

The `1password` skill (the `op` CLI, `brew install 1password-cli`) is unusually careful, and the details matter: - Verify the CLI first: `op --version`. - Confirm desktop-app integration is enabled and the app is unlocked before signing in. - **All `op` commands run inside a fresh tmux session — no direct `op` calls outside tmux.** That tmux requirement is a real gotcha: it isolates the session and avoids leaking secrets into shell history or a shared TTY. The skill also keeps install steps in `references/get-started.md` rather than guessing, and ships real examples in `references/cli-examples.md`.

Use case: Reading/injecting/running secrets via op without leaking them into shell history.

# Secrets and the fresh-terminal problem A secret-reading tool that asks for authorisation interacts badly with an agent shell that gives every command a new terminal. The prompt arrives on a terminal that is already gone, the read errors, and the failure looks like a wrong credential rather than a lost session. The fix is to hold one interactive session open for all secret operations. ## Order of operations matters Work through the checks in sequence and stop at the first failure. Verifying the tool is installed, confirming the desktop integration is enabled and the vault unlocked, authorising inside a persistent session, and confirming identity before the first read - each step makes the next one's failure unambiguous. ```python CHECKS = [ ("cli_present", "the command reports a version"), ("app_locked", "the desktop app is unlocked"), ("authorised", "sign-in completed inside the persistent session"), ("identity_confirmed", "the identity check succeeds before any secret read"), ] def diagnose(observed): for name, expectation in CHECKS: if not observed.get(name): return {"failed_at": name, "expectation": expectation} return {"failed_at": None} print(diagnose({"cli_present": True, "app_locked": False})) ``` The value of this shape is that a failure names the step, so a locked vault is never misreported as a bad credential. ## Never print a value Read the name of a secret and inject it where it is used. Echoing a secret into a transcript places it in the conversation record, the logs, and anything that later summarises the session. If a value must be compared, compare a hash or a prefix, never the whole string. ## Multi-account environments An explicit account selector removes ambiguity when more than one account is signed in, and the identity check after selecting the account is what proves which one is actually active. ## Tips - Keep one persistent interactive session for secret operations instead of starting a new one per command. - Confirm identity after selecting an account, not before, or a multi-account setup will read from the wrong vault. - Reference secrets by name and inject at the point of use so no value lands in the transcript. - Gotcha: a prompt on a fresh terminal disappears with that terminal, so the resulting error looks like a credential problem when the session is the real issue. - Gotcha: an unlocked desktop app is part of the chain; locking it mid-run breaks reads that worked minutes earlier.