1Password CLI vs Doppler vs InfisicalReal workflow comparison for coding agents

Three CLI tools. One goal. Very different assumptions about who runs the command.

1Password CLI (op), Doppler, and Infisical have each staked out the same territory: replace scattered .env files with a structured, audited, CLI-driven secrets workflow. They have converged on the same surface command (op run, doppler run, infisical run) that injects secrets as environment variables into a subprocess. The UX similarity is not accidental. It is what a solved problem looks like on the outside.

The differences show up inside. Authentication models, team sharing primitives, audit log scope, offline behavior, and license terms all diverge in ways that matter when you are picking a tool to use for years, not months. They diverge further when the "user" running the secrets command is a Claude Code session at 11pm on a Friday rather than a developer at a keyboard.

GitGuardian's State of Secrets Sprawl 2026 clocked AI-service token leaks at 81% year-over-year growth. The primary driver is not novel attacks. It is ambient secrets in developer environments meeting agents that inherit those environments wholesale. The choice of secrets tool shapes how bad that exposure gets.

What to know in 60 seconds

• All three tools expose a run command that wraps a subprocess with injected env vars. The mechanics are similar. The auth behind them is not.
• 1Password CLI ties authentication to a device and (on Mac) to Touch ID or a system keychain unlock. That flow breaks in headless CI and non-interactive agent sessions.
• Doppler and Infisical both use a long-lived API token (DOPPLER_TOKEN, INFISICAL_TOKEN) as the secret-zero. That token lives in your environment, which an agent can read and persist.
• Doppler is SaaS-only. Infisical can be self-hosted. 1Password is SaaS-only for secret storage, though vault items sync locally via the desktop app.
• Audit log access costs money on all three. 1Password events require Business tier. Doppler's audit trail is on paid plans. Infisical's is available on the Cloud or self-hosted with the appropriate plan.
• None of the three ships per-agent-session scoping out of the box. That is the gap for AI coding agent workflows.

Install and auth setup

Getting any of these running takes under ten minutes. Staying authenticated is where they differ.

For 1Password, you install the op CLI and connect it to your desktop app. On macOS, op signin links to the desktop app and subsequent calls can authenticate via Touch ID through op run with --no-masking. The desktop app must be running. On Linux without a GUI, you use a service account token or a device enrollment flow. The service account path is what CI uses, and it is separate from your personal vault with a separate credential to manage.

Doppler's install is brew install dopplerhq/cli/doppler on Mac or a curl script on Linux. doppler login opens a browser. You get an OAuth token scoped to your Doppler account. doppler setup picks the project and config (their environment name). After that, doppler run -- your-command works anywhere the CLI is installed and that token is present. The token lives in a config file at ~/.config/doppler/.doppler.yaml.

Infisical follows the same browser-OAuth pattern. brew install infisical/get-cli/infisical, infisical login, browser opens, token saved. infisical run -- your-command injects secrets from the linked project. For machine auth (CI, agents) they use machine identities with a token or a Universal Auth client-ID/secret pair.

On raw install friction: all three are similar. The real setup cost is connecting your first project and migrating secrets in. That is a half-day of work for a project with 20-30 secrets and some environment variants.

Daily UX: the run command in practice

All three tools converge on wrapping subprocesses:

op run --env-file=.env.template -- node server.js
doppler run -- node server.js
infisical run -- node server.js

1Password's approach is template-based. You write a .env.template file (or reference files) with op://vault/item/field URIs, and op run resolves them at invocation time. This means your template file commits to version control (no secrets in it, just references) and the actual values never touch the repo. Clean separation.

The performance cost: each invocation makes network calls to 1Password's servers to resolve the references. On a fast connection this is 100-300ms overhead. On degraded connectivity or in CI jobs that spawn many subprocesses, it adds up. 1Password's CLI does not cache resolved values between invocations by default.

Doppler's model is config-pull. When you run doppler run, it pulls the entire config for the current environment from the API and injects all of it as environment variables. No template file. No reference syntax. Fast once the pull completes. The tradeoff: you cannot selectively inject. Your subprocess gets everything in the Doppler config, not just what it needs.

Infisical works the same way as Doppler for the basic run command: pull the environment, inject everything. They also support a --secret-overrides flag and a --command option for inline commands. Their CLI has slightly more flags than Doppler's, which is either more flexible or more surface area to learn, depending on your preference.

For daily developer use, the choice mostly comes down to whether you want reference-based injection (1Password) or config-pull injection (Doppler, Infisical). Reference-based is more precise. Config-pull is less setup.

Team sharing model

1Password organizes around vaults. You create a vault per project or per environment, invite team members to that vault, and secrets are available to everyone in the vault. Sharing granularity is at the vault level, not the individual secret level (though item-level sharing is possible with limitations). The vault structure means access control is coarse by default: you have access to the whole vault or none of it.

On the plus side, 1Password's sharing primitives are designed for trust. You can share an item with a specific person via their 1Password account, time-limited, and it works without the recipient needing to be on your team plan. For small teams sharing credentials with contractors, this is genuinely useful.

Doppler organizes around projects and configs. A project is a service or application. A config is an environment (dev, staging, production). Team members get access to projects. Within a project, you can restrict access to specific configs (e.g., a contractor gets dev but not production). Service tokens scope down further: a token for one config, read-only, revocable. For teams that think in apps and environments rather than in vaults, this model fits better.

Infisical maps to the same project/environment hierarchy but adds fine-grained secret-level RBAC on paid plans. You can say "this team member can read DATABASE_URL but not STRIPE_SECRET_KEY." That is genuinely more granular than Doppler or 1Password for secrets-level access control. Whether your team needs that granularity is a different question.

For a solo developer: all three work. For a 5-person team: Doppler's project model usually fits engineering teams better than 1Password's vault model. For a 25-person team: Infisical's RBAC or Doppler's RBAC become meaningfully important.

Audit log capabilities

This is where pricing gates the comparison most visibly.

1Password's event logs cover sign-ins, item access, sharing events, and vault modifications. They are available through the 1Password Business tier (minimum per-seat billing applies) via the Events API and integrations to SIEM tools. The individual and family plans have no event logs. If you are on Teams (not Business), audit coverage depends on the exact feature set at your tier.

Doppler's audit trail is on paid plans. The free tier logs basic events. Activity logs on paid tiers cover secret access and config pulls, filterable by user and timestamp. Doppler also ships a webhook on paid tiers that you can use to stream events to a SIEM or a logging service.

Infisical's audit logs are available on Cloud (paid) and self-hosted. The self-hosted path gives you the most control: the logs stay in your infrastructure, you set retention policy, you control export. The quality of the audit log covers secret reads, writes, and deletes, with user attribution.

None of the three ties audit events to specific subprocesses or agent sessions. They record that a pull happened, from which account or service token, at what time. They do not record which child process within an agent session consumed the value or what happened to it after. For forensic questions like "did the Claude Code session from Tuesday pull the production Stripe key?", all three give you a partial answer: "the service token associated with that session pulled the Stripe config at 14:32." What happened after the pull is not logged.

Env var injection vs file injection

All three tools default to environment variable injection. This is correct for most cases. The value exists in the child process's memory, does not touch the filesystem, and disappears when the process exits.

The risk is that environment variables are visible to any code running in that process. An agent that receives a subprocess with injected env vars can read those variables, write them to a file, or pass them in a tool call. The injection model prevents the secret from living in ambient shell state before the subprocess starts, but it does not constrain what the subprocess does with the values.

1Password supports a template mode where secrets are written to a temp file (mode 0600) that is removed after the command completes. This is useful when a tool needs to read a credential from a file rather than from an environment variable. The 1Password SSH agent is a separate mechanism: it brokers SSH key signing operations so the private key never leaves the 1Password process.

Doppler and Infisical both have a --format dotenv flag that writes secrets to stdout in dotenv format, which you can pipe to a file. This is file injection by piping, not by default. Neither has a built-in temp-file mode that cleans up automatically.

For agent runtimes, env var injection is the safer default. File injection that persists through the session is the surface that caused the Knostic disclosures in February 2026, where coding-agent state files captured environment data from sessions.

CI/CD integration

Doppler has the strongest native CI integration story. They maintain first-party integrations with GitHub Actions, GitLab CI, CircleCI, Render, Vercel, Railway, and several others. The GitHub Actions integration injects secrets directly into the runner environment without the CLI. For teams already on these platforms, Doppler reduces CI secrets setup to "connect the integration, select the config."

Infisical has a comparable list of CI integrations and adds a Kubernetes operator for secret injection into pods. The self-hosted path makes Infisical more attractive for teams running on-premises CI (Jenkins, self-hosted GitLab) because the Infisical server can live inside the same network.

1Password's CI path goes through service accounts. You create a service account, generate a token, put that token in the CI secrets store (GitHub encrypted secrets, etc.), and the CI job uses it to authenticate op run. This works but it is an extra credential to manage: the 1Password service account token is a secret that unlocks other secrets, stored in GitHub Actions secrets. You have not eliminated the "secret that unlocks secrets" problem, you have just moved it one layer up.

For CI specifically, Doppler's platform integrations are the lowest-friction option. Infisical is competitive if you self-host. 1Password CI requires a service account credential management layer that the other two do not.

Cost at solo, 5-person, and 25-person scale

Prices shift frequently and the detail here will age. Use these as rough calibration, not purchasing quotes.

At solo scale: Doppler's free tier handles one project with unlimited secrets and 5 users. Infisical's free tier is similar. 1Password's cheapest individual plan is around $3/month (billed annually) and includes the CLI but not audit logs. For a solo developer who does not need audit, 1Password's personal plan is cheaper than a Doppler paid plan but more expensive than Doppler's free tier.

At 5-person scale: Doppler's paid tier runs roughly $10-18 per user per month depending on the plan tier. Infisical Cloud is in a similar range. 1Password Teams runs around $4-5 per user per month but lacks the audit features that Doppler and Infisical include at that tier. Getting to comparable audit coverage on 1Password requires the Business plan at a higher per-seat cost.

At 25-person scale: all three require paid plans with per-seat billing. The gap narrows on a per-seat basis but the feature differences matter more. Infisical self-hosted on this scale can eliminate the per-seat SaaS cost entirely, replacing it with infrastructure cost you control.

Infisical's self-hosted option is the only path to "zero per-seat licensing cost" for larger teams. The ops overhead is real: you run a PostgreSQL database, a Redis instance, and the Infisical service itself. For a 25-person team with dedicated DevOps capacity, this is feasible. For a 5-person team without it, the SaaS tier is the pragmatic choice.

License model

1Password is proprietary, closed-source. No source access. No self-hosting option. Your secrets infrastructure depends on 1Password as a company.

Doppler is proprietary SaaS. No self-hosting. Source is not available. Same dependency shape as 1Password.

Infisical is open source under MIT for the core. The hosted SaaS builds on it. You can self-host the full stack from the public repo. Their enterprise features (advanced RBAC, SAML, SCIM, some audit features) are behind a commercial license. The BSL and MIT dual-licensing situation is worth reading before you assume everything is MIT.

For teams with compliance requirements around vendor lock-in, data residency, or open-source dependencies, Infisical's open-source core is the differentiator. For teams that do not have those requirements, the license difference is mostly academic until one of these companies changes its pricing or gets acquired.

What breaks when you forget your password

This question is underrated in comparison posts.

For 1Password: your Master Password encrypts the local vault and is used to derive the encryption key. 1Password uses the Secret Key as a second factor in the encryption (account key combined with your Master Password). If you lose both, account recovery requires your Emergency Kit and a trusted family/team member to initiate recovery. If your Emergency Kit is also gone, the vault data is inaccessible. 1Password cannot recover it because they do not hold the keys. This is correct cryptographic behavior and it is genuinely surprising to people who expect SaaS "forgot your password" flows.

For Doppler: you log in via OAuth (Google, GitHub, etc.). Losing your Doppler password is a password reset with your email provider. Your secrets are decrypted server-side at Doppler using keys you do not control. This is simpler recovery but a different trust model: Doppler can theoretically access your secrets.

For Infisical cloud: same as Doppler. OAuth-based login, Infisical manages encryption keys server-side, password reset via email. For self-hosted Infisical, it depends on how you configured the instance and who holds the encryption keys.

The 1Password model gives you strongest cryptographic guarantees at the cost of account recovery complexity. Doppler and Infisical cloud give you easier recovery at the cost of trusting the vendor with decryption capability.

The 12-row feature matrix

Feature	1Password CLI	Doppler	Infisical	hasp
Install method	brew + desktop app link	brew / curl	brew / curl	curl install script
Auth mechanism	Device trust + Touch ID / service account	Browser OAuth / service token	Browser OAuth / machine identity	Local passphrase (Argon2id)
Run command	op run	doppler run	infisical run	hasp run
Injection mode	Env var (+ template file)	Env var (full config pull)	Env var (full config pull)	Env var, temp file, temp dotenv
Per-agent scoping	Vault-level only	Config-level only	Secret-level RBAC (paid)	Per-profile, per-session
Audit log	Business tier, Events API	Paid tier, dashboard + webhook	Paid or self-hosted	Local HMAC-chained, hasp audit
CI/CD integration	Service account token	Native platform integrations	Native + K8s operator	Not applicable (local-first)
Self-host option	No	No	Yes (MIT core)	N/A (no server)
Offline operation	No (requires server)	No	Partial (self-hosted)	Yes
Cost (solo)	~$3/mo individual	Free tier available	Free tier available	Free (FCL-1.0)
Cost (5 seats)	~$4-5/seat Teams	~$10-18/seat paid	~similar to Doppler	Free
License	Proprietary	Proprietary	MIT core + commercial extras	FCL-1.0 (Apache 2.0 in 2027)

How each one fails AI agents specifically

This is the section the tool marketing does not write.

1Password assumes Touch ID is available

On a developer's Mac, op run authenticates via the desktop app and Touch ID (or macOS keychain unlock). This is a good UX for a human at a keyboard. An AI coding agent running at 2am in a terminal session, triggered by a file watcher or a remote event, is not a human at a keyboard. If the desktop app has locked (screen lock, idle timeout, system sleep), op run blocks waiting for biometric confirmation that never arrives.

The workaround for non-interactive contexts is a service account. But service accounts are a separate credential type with a separate token, and that token has to live somewhere in the agent's environment. You are back to "a secret that unlocks other secrets" in the place you were trying to eliminate it from.

For developers who use Claude Code or Codex CLI in long-running background sessions, 1Password's device-trust model creates friction at exactly the moments the agent needs to act. The tool was built for humans who can tap a finger. It was not rebuilt for processes that run unattended.

Doppler centralizes everything, which is fine for teams and bad for trust boundaries

Doppler's model is elegant for teams: one canonical set of secrets per environment, accessible to every authorized service. The same design that makes team collaboration easy makes per-agent trust boundaries impossible.

When you run doppler run -- claude code, the agent session inherits a DOPPLER_TOKEN. That token is the credential that unlocks all secrets in the current Doppler config. If the Claude Code session writes a state file (and it does, in .claude/settings.local.json, as Knostic documented), that token can appear in the state file. The next session reads the state file and inherits the token. The token is not session-scoped. It does not expire after the agent session ends.

Doppler does not yet have a mechanism to issue a Doppler token that is valid for exactly one doppler run invocation and expires when the child process exits. The product was not designed for that granularity of trust. It was designed for services that need consistent access to a stable config. Those are different requirements.

Infisical's self-hosted setup means another service to maintain

Infisical's open-source option is genuinely appealing. No SaaS dependency, no per-seat cost at scale, data stays in your infrastructure. The practical cost is that you now run a secrets service as a first-class operational dependency.

Infisical's self-hosted stack requires PostgreSQL, Redis, and the Infisical application server. The application server needs TLS. The database needs backups. Upgrades need testing. For a 25-person team with DevOps capacity, this is routine. For a solo developer or a 3-person startup, it is another service in the on-call rotation that can fail at 2am and take your secrets with it.

The failure mode is specific: if your self-hosted Infisical instance is down, infisical run fails and your agent cannot start its subprocess. That is better than a data breach, but it is a hard dependency on service availability that Doppler's SaaS model at least offloads to their infrastructure team.

For teams choosing Infisical primarily to avoid SaaS cost, the ops overhead of self-hosting at small team scale often exceeds the SaaS cost within six months. The break-even is roughly 10-15 seats where the licensing cost difference outweighs the operational cost difference.

Concrete picks by team size

Solo developer, Mac, already paying for 1Password: use op run. The Touch ID UX is genuinely good for interactive sessions. Add a service account for CI. Accept that long-running agent sessions will occasionally block on re-auth.

Solo developer, not on 1Password, cost-conscious: use Doppler's free tier for now. It is the lowest-friction path to "stop committing secrets." Revisit when you need audit logs or per-agent scoping.

2-5 person team, cloud-first, CI-heavy: Doppler. The native CI integrations are worth paying for. Doppler's project/config model fits engineering team workflows well. Budget for a paid tier once you need audit.

5-25 person team, compliance requirements (SOC 2, PCI-DSS): Infisical cloud (for simplicity) or HashiCorp Vault (for strongest audit). Neither Doppler nor 1Password gives you the self-hosted option that some compliance frameworks require.

25-person team, strong DevOps capacity, cost-sensitive: Infisical self-hosted. The per-seat cost savings at this scale justify the ops overhead if you have the capacity.

Any team using AI coding agents in long-running unattended sessions: all three tools need a wrapper to work correctly. Service accounts for 1Password, scoped tokens for Doppler, machine identities for Infisical. None ships with per-session scoping or an agent-specific audit trail by default.

A checklist you can paste into a decision doc

## CLI secrets tool evaluation checklist

Auth model
- [ ] Does the tool work non-interactively (no Touch ID, no browser)?
- [ ] What credential unlocks the tool, and where does that credential live?
- [ ] Is there a path to per-session credentials that expire when the process ends?

Agent runtime
- [ ] Can the agent session's token be scoped to specific secrets only?
- [ ] Does the tool block on re-auth during a long-running agent session?
- [ ] After `run` exits, does anything persist on disk?

Audit
- [ ] What tier of plan do you need to access audit logs?
- [ ] Do logs record which service token / agent pulled which secret?
- [ ] Can you filter logs by time range and export them?

CI/CD
- [ ] Does the tool have a native integration with your CI platform?
- [ ] What is the credential management story for CI (service account, OAuth, etc.)?
- [ ] What is the failure mode if the secrets service is unreachable during CI?

Cost and license
- [ ] What is the cost at your current team size and at 2x growth?
- [ ] Is self-hosting an option if the vendor changes pricing or gets acquired?
- [ ] What is the account recovery story if you lose your device?

What this means for your stack

The run command pattern, op run, doppler run, infisical run, is a genuine improvement over ambient environment variables. It narrows the window when a secret is exposed and prevents the secret from living in your shell's permanent environment. That matters. Any of these tools is better than export STRIPE_KEY=sk_live_... in ~/.zshrc.

The gap for AI coding agent workflows is that none of the three ships with per-session scoping, process-tree-limited grants, or an audit log that tells you which subprocess inside an agent session touched which secret. They were built for services and humans. An agent that runs for hours, spawns many subprocesses, and writes state files is a different shape of consumer.

hasp is one implementation that addresses that shape directly: a local vault with Argon2id encryption, per-profile grants with a 24-hour ceiling, injection via env var or temp file (mode 0600) into a bounded process tree, and an HMAC-chained audit log at ~/.hasp/audit.jsonl that hasp audit --verify can check for tampering. curl -fsSL https://gethasp.com/install.sh | sh, hasp setup, connect a project, and the next agent session gets a reference instead of a key. Source-available (FCL-1.0), local-first, macOS and Linux, no account required.

The pick between 1Password, Doppler, and Infisical comes down to your team size, CI platform, and tolerance for ops overhead. The pick between all of them and an agent-native broker comes down to whether you trust a tool designed for human workflows to handle a non-human consumer correctly.