1Password Integration with OpenClaw: Config, Skills, and MCP

OpenClaw integrates with 1Password through four distinct mechanisms:

• Config secrets: any SecretRef field in openclaw.json can be resolved at runtime through the op CLI, which keeps API keys out of the config file.
• Agent workflows: the included 1password skill instructs agents on how to sign in and read or inject secrets using op for their own purposes.
• Desktop environments: the official 1Password MCP server provides interactive desktop agents with approved access to 1Password Environments.
• Browser sign-in: the claude-cli backend can leverage Claude Code's Chrome integration with 1Password for Claude, enabling the agent to sign in to websites without the password ever being exposed to the model or OpenClaw.

Requirements

• The 1Password CLI (op) must be installed on the Gateway host.
• A 1Password service account is needed for the unattended plugin paths.
• For direct skill workflows, you need either a service account, desktop app integration, or standalone op signin.

Resolve config secrets with the plugin

Activate the bundled plugin and create its service-account token file:

openclaw plugins enable onepassword
mkdir -p ~/.openclaw/credentials/onepassword
chmod 700 ~/.openclaw/credentials/onepassword
printf '%s' "$OP_SERVICE_ACCOUNT_TOKEN" > \
  ~/.openclaw/credentials/onepassword/service-account-token
chmod 600 ~/.openclaw/credentials/onepassword/service-account-token
unset OP_SERVICE_ACCOUNT_TOKEN

When OPENCLAW_STATE_DIR is set, that directory is used instead of ~/.openclaw. Then create and apply a SecretRef plan:

openclaw onepassword secretref setup \
  --openai-id op://Automation/OpenAI/credential \
  --anthropic-id op://Automation/Anthropic/credential \
  --plan-out ./openclaw-1password-secrets-plan.json

openclaw onepassword secretref status
openclaw secrets apply --from ./openclaw-1password-secrets-plan.json --dry-run --allow-exec
openclaw secrets apply --from ./openclaw-1password-secrets-plan.json --allow-exec
openclaw secrets audit --check --allow-exec
openclaw secrets reload

The setup command needs at least one target. Before applying the plan, status might show the provider as unconfigured while still displaying prerequisites ready: yes; after apply, ready: yes verifies that the provider, the trusted op executable, and the accepted non-empty token file are all in place.

The plugin accepts native op://<vault>/<item>/<field> and op://<vault>/<item>/<section>/<field> references. Only registered OpenClaw credential targets are resolved, parallel op read calls are bounded, and desktop-app integration is forced off. For manual configuration, custom targets, and the separate audited agent tool, see the plugin guide.

The 1password skill for agents

OpenClaw ships with a 1password skill that guides agents in picking an available auth mode, verifying access, and choosing op run or op inject over writing secret values to disk.

Agents rely on it for workflows that deliberately go beyond the plugin's narrow contracts, such as creating or rotating an item or injecting credentials into a one-off command. If a credential is already linked to an OpenClaw SecretRef target, the owning OpenClaw workflow should handle resolution; the agent does not need to invoke op directly.

Official 1Password MCP server

The official MCP server is a beta desktop workflow for 1Password Environments. It depends on the 1Password desktop app and requires explicit approval for every interaction. It can handle environment variable names and mount values into a local process through an in-memory .env file; secret values are never returned to the MCP client or model.

It does not offer headless service-account access to arbitrary vault items, and the OpenClaw plugin never calls it. If an MCP-managed Environment starts OpenClaw with variables already mounted, use OpenClaw's env SecretRefs for those values. When the Gateway itself should resolve 1Password references at startup or reload, the plugin is the right choice.

Browser sign-in with 1Password for Claude

1Password for Claude enables Claude to request a login while the 1Password browser extension fills the credential directly into the page over an encrypted channel. The secret is never exposed to the model context, the transcript, or OpenClaw. When OpenClaw runs the claude-cli backend with Claude Code's Chrome integration enabled, agent tasks can use that flow for websites that need a real signed-in session.

Beyond the backend itself, this setup requires:

• A macOS gateway host with Chrome, the Claude in Chrome extension connected, the 1Password desktop app, and the 1Password browser extension (all 8.12.28 or later).
• Claude Code signed in to a direct Anthropic plan (Pro, Max, Team, or Enterprise). Chrome integration is unavailable through Amazon Bedrock, Google Cloud, or other third-party providers.
• A one-time 1Password connection on the Anthropic side: 1Password for Claude is configured through the Claude desktop app or extension flow described in 1Password's guide, and it is currently a macOS beta. On 1Password Business, an administrator must first enable "Allow AI agents to autofill for users" under Policies; Anthropic Team/Enterprise plans also have the integration off until an Owner turns it on.
• A CLI backend plugin that adds --chrome to the Claude launch args; the bundled backend does not enable Chrome.
• A person at the gateway host: every credential use triggers a 1Password prompt confirmed there (for example with Touch ID). Under a restrictive exec policy the browser tool calls themselves are also relayed to your channel as OpenClaw approvals first.

Before wiring this into OpenClaw, test the pieces in an interactive session on the gateway host: run claude --chrome, confirm the extension connects, and check that the claude-in-chrome tools include the credential tools. If they are not visible there, they will not be visible through OpenClaw either.

One-time passcodes are filled by 1Password on the same page; never relay verification codes or passwords through chat. Headless or remote gateways cannot use this flow today because the approval and the browser both reside on the gateway host.

Security notes

• Secret values resolved through exec providers stay in Gateway memory; config snapshots and config.get responses redact SecretRef fields.
• The plugin resolver and broker enforce OP_LOAD_DESKTOP_APP_SETTINGS=false and OP_BIOMETRIC_UNLOCK_ENABLED=false so unattended reads cannot trigger desktop approval or macOS permission dialogs.
• Before passing the service-account token, the plugin resolves the op executable and rejects paths that are writable by another local account or have unverifiable Windows ACLs or ownership. An absolute CLAW_1PASSWORD_OP override is subject to the same check.
• A resolver request is limited to 32 references. Reads run four at a time with a seven-second per-read timeout; the provider-wide 90-second timeout covers the full supported batch plus process and permission-check overhead.
• Never place secret values in openclaw.json, logs, or chat. Scope the service account to only the vaults and items OpenClaw needs.

Troubleshooting

• op is missing: install the CLI on the Gateway host, ensure it is on PATH, or set CLAW_1PASSWORD_OP to its absolute path.
• op is not trusted: use an executable owned by the current user or root and remove group/other write access from the executable and its parent chain.
• Authentication fails: check the plugin token file, its contents, and the service account's vault permissions with openclaw onepassword status.
• A reference is rejected: include the vault explicitly and use stable vault, item, section, and field IDs when names are long or contain unsupported 1Password reference characters.