2.5k
GitHub Stars
2
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill openclaw/skills --skill 1password- _meta.json272 B
- SKILL.md2.4 KB
Overview
This skill guides secure setup and use of the 1Password CLI (op) with enforced tmux-based workflows. It documents installation verification, desktop app integration, sign-in and multi-account handling, and safe secret access patterns. The focus is operational reliability and avoiding common pitfalls that cause prompts or lost sessions.
How this skill works
The skill inspects the host OS and shell, verifies op is installed and the desktop app is integrated and unlocked, and requires running all op commands inside a fresh tmux session to preserve TTY state. It provides the sign-in and verification sequence (op signin, op whoami, op vault list) and recommends op run/op inject for ephemeral secret handling. Multi-account behavior is handled via --account or the OP_ACCOUNT env var.
When to use it
- Installing or verifying the 1Password CLI on a machine
- Enabling and confirming desktop app integration before CLI sign-in
- Signing in to a single or multiple 1Password accounts from the CLI
- Reading, injecting, or running secrets via op in automation
- Any scenario where op must run reliably without interactive TTY failures
Best practices
- Always run op inside a fresh tmux session with a unique socket and session name
- Verify op --version and op whoami inside the tmux session before reading secrets
- Prefer op run or op inject instead of writing secrets to disk
- Never paste secrets into logs, chat, or code; capture output carefully
- If app integration is unavailable use op account add and follow signin prompts
Example use cases
- Automated CI step that needs a short-lived secret: create tmux socket, op signin, then op run to execute a command with injected credentials
- Local developer onboarding: confirm desktop app integration, sign in inside tmux, list vaults and confirm access
- Multi-account workflows: set OP_ACCOUNT or use --account to target a different 1Password account inside tmux
- Recovery from 'account is not signed in' errors: start a new tmux session, run op signin and authorize via app, then op whoami to verify
FAQ
The CLI and desktop app sign-in flows require a persistent TTY. A fresh tmux session preserves a stable socket and prevents repeated prompts or failures caused by ephemeral TTYs.
What if I can't use tmux on this host?
Stop and ask for guidance. Running op outside tmux is unsupported by this workflow; if unavoidable, use op account add and follow non-app integration sign-in, but expect higher fragility.