OpenClaw and 1Password

The docs describe four independent ways OpenClaw pairs with 1Password: any secret-reference field in the config can resolve through the 1Password CLI at runtime, so API keys never live in the config file; a bundled skill teaches agents to sign in and read or inject secrets for their own tasks; the official MCP server gives interactive desktop agents approved access to 1Password Environments; and the Claude CLI backend can use Claude Code’s Chrome integration with 1Password for Claude to sign the agent in to websites without the password ever reaching the model. Here is each path, the plugin setup step by step, the security rules, and the migration the troubleshooting section walks through.

The four paths

• Config secrets: enable the bundled plugin, create a service-account token file under the credentials directory with tight permissions from a token exported in the shell and then cleared, generate a secret-reference plan naming the targets, check status, apply with a dry run first, audit, and reload; after apply the status reports the provider, the trusted executable and the accepted token file as ready.
• The plugin accepts native vault, item and field references, resolves only registered OpenClaw credential targets, bounds parallel reads, and forces desktop-app integration off.
• The skill teaches an agent to select an available auth mode, verify access, and prefer running or injecting over writing secret values to disk; it is for workflows beyond the plugin’s narrow contract, such as creating or rotating an item, and a credential already wired to a reference target does not need the agent to call the CLI at all.
• The official MCP server is a beta desktop workflow that needs the desktop app and explicit approval per interaction; it mounts values into a local process through an in-memory env file, never returns secret values to the client or model, offers no headless service-account access, and the plugin does not call it.

Never place secret values in openclaw.json, logs, or chat.

Browser sign-in

1Password for Claude lets Claude request a login while the browser extension fills the credential directly into the page over an encrypted channel, so the secret never enters the model context, the transcript or OpenClaw. It needs a macOS Gateway host with Chrome, the Claude in Chrome extension connected, the desktop app and the browser extension at 8.12.28 or later, Claude Code signed in to a direct Anthropic plan, since the Chrome integration is not available through third-party providers, the one-time connection on Anthropic’s side with an administrator enabling AI-agent autofill on a business account, a CLI backend plugin that adds the Chrome flag, and a person at the host, because every credential use shows a prompt confirmed there. Verify the pieces in an interactive session first; one-time passcodes are filled on the page and never relayed through chat; headless or remote Gateways cannot use the flow today.

The security rules

• Values resolved through exec providers stay in Gateway memory, and config snapshots and reads redact reference fields; the resolver forces the desktop-app settings and biometric unlock off so unattended reads cannot trigger approval dialogs.
• Before passing the service-account token, the plugin resolves the executable and rejects paths writable by another local account or with unverifiable ownership; a resolver request is limited to 32 references, reads run four at a time with a seven-second per-read timeout, and a 90-second provider-wide timeout covers the batch.
• Scope the service account to only the vaults and items OpenClaw needs, and keep secret values out of the config, the logs and chat.

OpenClaw secrets explains the reference syntax every field here uses, and OpenClaw and MCP the server model the official 1Password server follows.

Troubleshooting and the migration

A missing CLI needs installing or an absolute-path override; an untrusted one needs owner-only write access along its parent chain; failed auth is checked with the plugin status command; a rejected reference should name the vault and use stable ids. The Homebrew trap: a manual exec provider refuses a symlinked command, and resolving the link to a versioned path breaks on the next upgrade, so the docs point at the plugin flow, which resolves the executable from the Gateway’s path per request and follows a replacement link. Before migrating, map every credential target to the exact reference its old command reads, choose an unused provider alias if the name is taken, generate a plan with explicit target mappings, inspect it, and remove the old provider only after every reference has moved. OpenClaw and Claude Code and The OpenClaw browser tool are the two features the browser sign-in path sits on.

On Diali

On Diali the vault plays the role of the service account: keys are stored on our side, referenced by the config we generate, and never appear in a file you can open. Hosted OpenClaw on Diali is the assistant and Diali security describes the boundary.

• Plugin for config, skill for tasks, MCP for the desktop, Claude for sign-in.
• Thirty-two references, four reads at a time, seven seconds each.
• Use the plugin flow, not a symlinked exec provider.