1Password CLI for AI coding agentsWhere op works. Where it doesn't.

A thread on r/1Password from late 2025 asked a reasonable question: can you just use op run -- claude to feed Claude Code secrets safely? It got 67 upvotes and a mix of "yes, that's the right call" and "it depends what you mean by safe." Both camps were correct.

The op CLI is the right answer inside the category of "use a password manager." Biometric unlock, macOS keychain integration, op://vault/item/field template syntax for .env files, process-scoped injection via op run --. These are real wins. For a developer working interactively, op removes the worst habit in the industry: exporting secrets into the shell environment and leaving them there.

The problem is not with 1Password. The problem is that the person asking the question is no longer the one running commands.

When you wrap your entire Claude Code session with op run --, the agent inherits every injected variable for the lifetime of the process. The agent then spawns child processes of its own, writes state to disk, calls tools, and generates code that may reference or embed what it found in its environment. That is a different trust model than the one op run -- was designed for.

The short version

• op run -- injects secrets into a child process's environment and nowhere else. That is the correct behavior.
• When the child process is Claude Code, the agent inherits those secrets and keeps them in memory for the full session.
• Before Anthropic's late February 2026 patch, Claude Code wrote environment variables from each session into .claude/settings.local.json. Knostic found that file in roughly 1 in 13 npm packages.
• The op CLI has no visibility into what the child process does after it receives the variables. No per-command audit trail, no revocation, no scope limits inside the process.
• SSH agent for git operations is a genuine win and works well with AI-generated commits. That use case is straightforward.
• Per-command wrapping (op run -- pnpm test) is safer than wrapping the agent session. The discipline is harder to maintain.

What op does well

Run op run --env-file=.env.tmpl -- npm test and the secrets your test suite needs appear in that process and disappear when it exits. They never touch your shell history. They never land in .bashrc. If you forget to wrap a command, the child process gets nothing rather than inheriting a polluted environment from your interactive session.

The op://vault/item/field syntax in .env.tmpl files is clean to read and safe to commit. A file full of op:// references tells anyone reading the repo what credentials exist without exposing values. That is useful documentation as much as it is a security control.

Biometric unlock on macOS means the vault stays locked until you authenticate, and re-locks on timeout. For a developer running commands manually, that is about as good as local secret management gets.

SSH agent support means op can serve SSH keys to the agent process for git operations. Claude Code doing git commit and git push through the SSH agent works without the private key ever touching a file the agent writes to. This is a real win for AI-generated commits and one of the cleaner op use cases in this context.

Where the friction starts

Every CI run that needs secrets wants a service account token. That token is itself a secret you have to store somewhere, which puts you back at secret-zero. 1Password's answer to this is valid: store the service account token in your CI provider's secrets store, use it once to unlock the vault, pull everything else from there. That works, but it does not eliminate the bootstrapping problem, it defers it.

Each op run invocation takes around 200 milliseconds to unlock and resolve references. For a developer running one command at a time that cost is invisible. For an agent running 50 tool calls in a session, the latency adds up. More practically: you have to remember to wrap every command with op run --. When you forget, the child process gets nothing. When your agent forgets (because it generates shell commands the agent runner executes directly), the command runs without secrets and fails in ways that may be hard to diagnose.

1Password Watchtower provides audit events, but they are coarse. You can see that vault item X was accessed at time T. You cannot see which specific op run invocation accessed it, which command in the agent session triggered that invocation, or what the agent did with the value after it received it. For a compliance question like "did the agent use the production database token between 2pm and 4pm Tuesday?", the answer requires correlating Watchtower events with agent session logs manually.

Wrapping the agent versus wrapping the commands

This is where most of the r/1Password thread went wrong. Several replies suggested op run -- claude as the solution. The intent is right: you want Claude Code to have access to secrets without you exporting them into your shell first. The execution creates a larger problem.

When you run op run -- claude, every variable in your .env.tmpl file lands in Claude Code's environment for the entire session. The agent can read STRIPE_SECRET_KEY, DATABASE_URL, OPENAI_API_KEY, and whatever else you templated. It holds all of them. If the agent writes a debug file, generates a test fixture, or logs its context, those values are in scope for every write operation for the next hour.

The safer pattern is wrapping specific commands the agent needs to execute:

op run --env-file=.env.tmpl -- pnpm test
op run --env-file=.stripe.tmpl -- node scripts/charge.js

This gives each command exactly the secrets it needs, and only for the duration of that command. The agent session itself gets no injected secrets unless it explicitly invokes a wrapped command.

The problem is that this requires discipline at every call site. When you define an agent tool that runs shell commands, you have to ensure the tool wrapper adds op run -- before each command. When the agent generates a shell script and executes it, the script needs to wrap its own commands. In practice this is hard to enforce, and missing one call site means a command either runs without credentials or falls back to secrets the agent found another way.

The disk-write problem the community underweighted

The r/1Password thread mostly focused on whether op run -- kept secrets out of the shell. It does. What the thread did not focus on was what happens after injection.

In February 2026, Knostic disclosed that Claude Code wrote environment variables from each session into .claude/settings.local.json. Anthropic patched this in late February. Before the patch, running op run -- claude meant the variables you injected at exec time could end up on disk in a predictable path, which npm publish would then ship to the registry.

The op CLI had no way to prevent this. Once a value lands in a process's environment, the CLI's job is done. What the process does with the value is outside 1Password's control. This is not a criticism of the design. It is what "process-scoped injection" means.

The same risk applies to any agent that writes session state to disk, logs its context for debugging, or generates code that embeds environment values in test fixtures or configuration files. op run -- prevents the values from persisting in your interactive shell. It does not prevent the child process from persisting them.

What the community gets right (and the limitation they accept)

The people in the r/1Password thread recommending op run -- are not wrong. For individual developer workflows, op removes the worst secret-management habits: export in .bashrc, plaintext in .env committed to git, credentials in shell history. Those habits cause real incidents. op run -- fixes them.

The limitation the community mostly accepted is that 1Password is a password manager built for humans unlocking credentials to use directly. The vault access model is: authenticate, retrieve, use. Revocation is manual. Scope is per-vault-item, not per-command. Audit granularity is per-access-event, not per-downstream-operation.

AI coding agents flip the model. The agent orchestrates dozens of child processes per session. The human is upstream, not in the loop for each individual command. The agent decides which commands run, in what order, with what inputs. Designing secret access around a human authenticating once and an agent inheriting the result puts a lot of trust in the agent's write discipline.

That is not a solvable problem at the password manager layer. It is a design constraint.

What you should actually do right now

## 1Password + AI agent security checklist

- [ ] .env.tmpl uses op:// references, committed to git
- [ ] .env files excluded from git, npmignore, dockerignore
- [ ] .claude/, .cursor/, .aider/ excluded from git and publish pipelines
- [ ] Agent sessions do not use op run -- claude (wrap commands, not the session)
- [ ] Each tool definition that runs shell commands wraps with op run --env-file=
- [ ] CI service account token stored in CI provider secrets, not in repo
- [ ] SSH agent configured for git operations (not a raw key file the agent can read)
- [ ] git log --all -- '.claude/*' clean (no state files in history)
- [ ] Rotated any credentials that were in scope during affected Claude Code versions
- [ ] Watchtower events reviewed for unexpected vault access during agent sessions

Run this against every repo where you have used Claude Code with 1Password integration. The checklist catches the most common gaps without requiring a different tool.

What this means for your stack

1Password CLI is the best individual answer in the "use a password manager" category. If you are not using it, start. It removes the habits that cause most credential leaks for individual developers. For teams using it in CI, the service account model is workable once the bootstrapping token lives in a proper secrets store.

The gap it does not close is agent-shaped workflows where the agent orchestrates child processes, writes state to disk, and may run for an extended session without a human reviewing each operation. For that pattern, you need a runtime broker: something that holds secrets in an encrypted local vault, grants per-process access at exec time, and keeps an append-only audit trail of which command received which credential. 1Password sits on the human side of the unlock boundary. A broker sits at the exec boundary, scoping each grant to one process, one session window.

hasp is one working implementation. curl -fsSL https://gethasp.com/install.sh | sh, hasp setup, connect a project, and the next agent session gets a reference rather than a live credential. Source-available (FCL-1.0), local-first, macOS and Linux, no account. The two tools are not in competition: 1Password holds your human secrets, a broker manages what each agent process receives.

The durable principle is that access control at the vault boundary does not substitute for access control at the process boundary. Agent sessions need both.