Add 1Password SecretRef plugin

[sallyom]

Summary

• Adds a bundled 1password plugin that provides a managed SecretRef exec provider for 1Password.
• Resolves SecretRefs through the official 1Password CLI (op) using service account or Connect auth env, while keeping resolved secrets out of OpenClaw config.
• Adds openclaw 1password status and openclaw 1password setup helpers for local and server workflows.
• Documents direct-host and container runtime requirements, including the fact that the plugin is bundled but the op CLI remains a runtime dependency.

Linked context

Companion to the bundled Vault SecretRef plugin work in #89255, adding the same plugin-managed SecretRef provider pattern for 1Password.

Real behavior proof

• Behavior addressed: OpenClaw can configure and use the bundled 1password SecretRef provider to resolve model provider credentials from 1Password without storing plaintext provider keys in OpenClaw config.
• Real environment tested: local Podman OpenClaw container using the bundled 1password extension, a mounted OpenClaw data volume, a maintainer-provided 1Password service account token, and default vault openclaw.
• Secret material handling: the service account token and resolved provider credentials were not printed. Status output reports only whether auth env is present.
• Exact setup behavior observed: the container image staged a Linux op binary from docker.io/1password/op:2, validated it with 2.34.1, and started the Gateway with CLAW_1PASSWORD_OP=/home/node/.openclaw/bin/op-wrapper.
• Evidence after fix: the onepassword provider was configured as a plugin-managed exec provider; the runtime saw the op wrapper; service account auth was present; the default vault was set.

From local run:

{
  "providerAlias": "onepassword",
  "provider": {
    "configured": true,
    "source": "exec",
    "pluginIntegration": {
      "pluginId": "1password",
      "integrationId": "onepassword"
    }
  },
  "opCommand": "/home/node/.openclaw/bin/op-wrapper",
  "opCommandAvailable": true,
  "authMode": "service-account",
  "hasServiceAccountToken": true,
  "hasConnectHost": false,
  "hasConnectToken": false,
  "defaultVault": "openclaw"
}

and

$ openclaw secrets audit --allow-exec
│
◇

OpenClaw 2026.6.11 (unknown) — Hot reload for config, cold sweat for deploys.

Secrets audit: findings. plaintext=1, unresolved=0, shadowed=0, legacy=0.
- [PLAINTEXT_FOUND] /home/node/.openclaw/openclaw.json:gateway.auth.token gateway.auth.token is stored as plaintext.

• Proof limitations or environment constraints: this proof used local Podman deployment. The op binary is intentionally not bundled into the plugin package; direct users and custom container images must provide a compatible 1Password CLI in the Gateway runtime.

Tests and validation

Commands run locally:

node scripts/run-vitest.mjs extensions/1password/src/cli.test.ts extensions/1password/index.test.ts extensions/1password/src/secret-ref-resolver.test.ts
pnpm tsgo:extensions
node scripts/run-oxlint.mjs --tsconfig config/tsconfig/oxlint.extensions.json extensions/1password
pnpm plugins:inventory:check
node --check extensions/1password/onepassword-secret-ref-resolver.js
git diff --check

CLI smoke checks:

pnpm openclaw 1password --help
pnpm openclaw 1password status --json
pnpm openclaw 1password setup --plan-out /tmp/openclaw-1password-cli-smoke.json --anthropic-id op://openclaw/Anthropic/credential

Notes:

• openclaw 1password --help correctly reports that the bundled plugin must be enabled first with openclaw plugins enable 1password, matching the Vault plugin behavior.
• The setup smoke generated a secrets apply plan containing a plugin-managed onepassword exec provider and a model provider SecretRef target.

Regression coverage added:

• Resolver tests for manifest integration metadata, inline test values, native op:// references, shorthand references with CLAW_1PASSWORD_VAULT, missing CLI diagnostics, and CLAW_1PASSWORD_VALUES_JSON not being passed through the manifest.
• CLI tests for setup plan generation, custom provider mapping, duplicate provider rejection, and traversal segment rejection.
• Plugin entry test for the lazy root CLI registration.

What failed before this fix:

• OpenClaw had the SecretRef provider contract but no bundled 1Password reference implementation.
• Operators had to configure a manual exec provider or external plugin wiring rather than using a bundled plugin-managed provider.

Risk checklist

• Did user-visible behavior change? Yes
• Did config, environment, or migration behavior change? Yes
• Did security, auth, secrets, network, or tool execution behavior change? Yes
• Highest-risk area: SecretRef resolution shells out to op, and the Gateway runtime must provide a trustworthy 1Password CLI plus scoped 1Password auth env.
• Risk mitigation: the provider is opt-in, the CLI surface requires openclaw plugins enable 1password, resolver execution is plugin-managed through manifest metadata, secret values are returned only through the SecretRef protocol, setup writes SecretRefs rather than plaintext, tests cover resolver and CLI plan behavior, and docs call out host/container op runtime requirements.

Current review state

Next action: maintainer/security review for the bundled exec resolver trust model and runtime op dependency.

Reviewer focus:

• SecretRef provider manifest shape and plugin-managed exec integration.
• 1Password id formats: native op://<vault>/<item>/<field>, <vault>/<item>/<field>, <vault>/<item>/<section>/<field>, and <item>/<field> with CLAW_1PASSWORD_VAULT.
• Bundled plugin exec resolver trust model: standard 1Password env is passed through, CLAW_1PASSWORD_OP can pin the CLI path, and failures avoid printing secret values.
• Docs clarity for direct host usage, service environments, and container images that must provide a Linux op binary.

[clawsweeper]

Codex review: found issues before merge. Reviewed July 11, 2026, 11:09 AM ET / 15:09 UTC.

Summary
Adds a bundled 1Password-backed SecretRef plugin, setup and status CLI commands, broader shared exec-ID validation, packaging, documentation, and regression tests.

PR surface: Source +828, Tests +543, Docs +284, Config +28, Other +6. Total +1689 across 26 files.

Reproducibility: yes. for both patch defects: a multi-ID request directly enters all-at-once child-process creation, and a setup plan using a custom alias is invisible to the hard-coded status reader.

Review metrics: 4 noteworthy metrics.

• Maximum resolver fanout: Up to 512 child processes. The core provider batch limit maps directly to simultaneous authenticated op read executions.
• Setup/status alias paths: 1 writer supports custom aliases; 1 reader hard-codes the default. The two CLI paths disagree about which configured provider status should report.
• Shared exec-ID contract: 256 restricted characters → 2048 printable ASCII characters. The validation change affects every exec SecretRef provider and gateway protocol consumer.
• New operator surface: 7 forwarded environment variables, 8 CLI options. Executable selection, authentication, account/cache behavior, default vault, plan generation, and target mapping add setup and upgrade considerations.

Stored data model
Persistent data-model change detected: serialized state: extensions/1password/onepassword-secret-ref-resolver.js, serialized state: extensions/1password/src/secret-ref-resolver.test.ts, vector/embedding metadata: extensions/1password/index.test.ts. Confirm migration or upgrade compatibility proof before merge.

Merge readiness
Overall: 🦐 gold shrimp
Proof: 🦞 diamond lobster
Patch quality: 🦐 gold shrimp
Result: needs maintainer review before merge.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• [P2] Bound op read concurrency and add multi-ID regression coverage.
• Make status alias-aware and test custom and ambiguous aliases.
• Obtain exact-head dependency authorization and maintainer/security approval.

Risk before merge

• [P1] A maximum provider batch can start up to 512 authenticated op processes concurrently, causing process pressure and excessive 1Password requests during startup, reload, audit, or apply preflight.
• [P1] Custom aliases produced by setup appear unconfigured in status, which gives operators misleading diagnostics for a valid configuration.
• [P1] The shared exec SecretRef grammar expands from a narrow 256-character contract to 2048 printable ASCII characters for every provider and protocol consumer.
• [P1] The external op binary and forwarded authentication environment become part of OpenClaw's credential trust boundary.
• [P1] The package and lockfile importer changes cannot land without exact-head dependency authorization or removal.

Maintainer options:

1. Repair, authorize, and approve (recommended)
   Bound child-process fanout, make status alias-aware, authorize the exact dependency graph, and approve the external CLI trust model before merge.
2. Keep the integration external
   Avoid adding the bundled execution and dependency boundary by publishing the provider through the external plugin ecosystem.

Next step before merge

• The code repairs are concrete, but the protected label plus dependency authorization and security/product decisions require human-owned follow-up.

Maintainer decision needed

• Question: After the two correctness defects are fixed, should OpenClaw bundle a 1Password SecretRef integration that executes an operator-selected op binary with forwarded authentication environment?
• Rationale: The fanout and alias defects have mechanical repairs, but accepting a bundled credential-execution boundary, shared SecretRef grammar expansion, and external runtime dependency requires explicit security and product intent.
• Likely owner: joshavant — The closest merged sibling history includes the exact alias-aware status behavior and SecretRef security hardening relevant to this decision.
• Options:
  • Repair and approve (recommended): Fix fanout and alias handling, then land only after exact-head SecretRef, dependency, and security approval.
  • Externalize the integration: Keep the generic SecretRef plugin seam in core and distribute the managed 1Password provider outside the bundled package.

Security
Needs attention: Unbounded credential-resolver process fanout, external CLI execution, and guarded dependency changes require repair or explicit approval before merge.

Review findings

• [P2] Bound the per-ID op read fanout — extensions/1password/onepassword-secret-ref-resolver.js:140-143
• [P2] Make status honor custom provider aliases — extensions/1password/src/cli.ts:453-457

Review details

Best possible solution:

Bound resolver concurrency, make status discover the configured plugin-integration alias with deterministic ambiguity handling, preserve core and gateway validation parity, and obtain exact-head security and dependency approval before landing the opt-in plugin.

Do we have a high-confidence way to reproduce the issue?

Yes for both patch defects: a multi-ID request directly enters all-at-once child-process creation, and a setup plan using a custom alias is invisible to the hard-coded status reader.

Is this the best way to solve the issue?

No in its current form; the plugin-managed architecture follows an established sibling pattern, but resolver concurrency and alias consistency must be fixed before maintainers decide whether to accept the bundled trust model.

Full review comments:

• [P2] Bound the per-ID op read fanout — extensions/1password/onepassword-secret-ref-resolver.js:140-143
resolveFromOnePassword starts one authenticated child process per requested ID inside a single Promise.all. Core accepts batches up to 512 references, so startup, reload, audit, or apply preflight can create hundreds of simultaneous op processes and requests; use a small fixed concurrency limit and add a multi-ID regression test.
  Confidence: 0.99
• [P2] Make status honor custom provider aliases — extensions/1password/src/cli.ts:453-457
setup --provider-alias writes the integration under the requested alias, but runStatus always reads and reports onepassword. A valid custom setup therefore appears unconfigured; locate the matching pluginIntegration entry, handle ambiguity deterministically, and cover custom aliases.
  Confidence: 0.99

Overall correctness: patch is incorrect
Overall confidence: 0.99

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against b3136854f0ed.

Label changes

Label changes:

• add merge-risk: 🚨 availability: A maximum provider batch can launch hundreds of external processes simultaneously during routine Gateway secret operations.
• remove merge-risk: 🚨 auth-provider: Current PR review merge-risk labels are merge-risk: 🚨 compatibility, merge-risk: 🚨 security-boundary, merge-risk: 🚨 availability.

Label justifications:

• P2: Two normal-priority correctness defects block an otherwise useful opt-in feature.
• merge-risk: 🚨 compatibility: The PR broadens a shared SecretRef identifier contract and adds new operator runtime and setup requirements.
• merge-risk: 🚨 security-boundary: The Gateway executes an operator-selected external binary with credential-bearing environment variables during secret resolution.
• merge-risk: 🚨 availability: A maximum provider batch can launch hundreds of external processes simultaneously during routine Gateway secret operations.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦞 diamond lobster and patch quality is 🦐 gold shrimp.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Sufficient (terminal): The PR body provides real Podman proof using op 2.34.1 and service-account authentication, showing configured provider status and audit output after the change without exposing secret values.
• proof: sufficient: Contributor real behavior proof is sufficient. The PR body provides real Podman proof using op 2.34.1 and service-account authentication, showing configured provider status and audit output after the change without exposing secret values.

Evidence reviewed

PR surface:

Source +828, Tests +543, Docs +284, Config +28, Other +6. Total +1689 across 26 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	7	836	8	+828
Tests	7	546	3	+543
Docs	9	300	16	+284
Config	2	28	0	+28
Generated	0	0	0	0
Other	1	6	0	+6
Total	26	1716	27	+1689

Security concerns:

• [medium] Bound credential-resolver process fanout — extensions/1password/onepassword-secret-ref-resolver.js:140
  A large request launches many op processes simultaneously while each inherits 1Password authentication environment, increasing availability and credential-boundary exposure.
  Confidence: 0.99
• [medium] Approve the external CLI trust model — extensions/1password/openclaw.plugin.json:18
CLAW_1PASSWORD_OP selects the executable receiving 1Password authentication environment, so binary provenance and service isolation require explicit approval.
  Confidence: 0.98
• [low] Resolve dependency authorization — extensions/1password/package.json:1
  The new workspace importer and package graph fields remain blocked until exact-head administrator or security authorization, or their removal.
  Confidence: 0.99

What I checked:

• Unbounded resolver fanout: The exact head maps every requested ID into one Promise.all, and each entry immediately starts an authenticated op read child process. (extensions/1password/onepassword-secret-ref-resolver.js:140, 5b5971e2de5d)
• Provider batch limit: Current main permits up to 512 references per provider, so the resolver can attempt hundreds of simultaneous child processes. (src/secrets/resolve.ts:53, b3136854f0ed)
• Status ignores setup aliases: Setup accepts and writes a custom provider alias, but status always reads and reports the hard-coded onepassword alias. (extensions/1password/src/cli.ts:453, 5b5971e2de5d)
• Sibling alias contract: The merged Vault sibling added alias-aware status handling in commit 81dd529, confirming the established behavior for plugin-managed providers. (extensions/vault/src/cli.ts:1, 81dd52949f38)
• Shared SDK provenance: The public SecretRef target seam reused by this branch originated in the adjacent Vault work at commit 7b04710. (src/plugin-sdk/secret-ref-runtime.ts:1, 7b0471042feb)
• Security ownership: CODEOWNERS routes the secrets runtime, gateway secret contracts, and relevant documentation to the OpenClaw security team. (.github/CODEOWNERS:30, b3136854f0ed)

Likely related people:

• joshavant: Authored the merged Vault alias-aware status behavior and several SecretRef security and plugin-policy hardening commits that define the closest sibling contract. (role: adjacent feature owner; confidence: high; commits: 81dd52949f38, d3452e4f5252, 655bae906b8d; files: extensions/vault/src/cli.ts, extensions/vault/vault-secret-ref-resolver.js, src/secrets)
• steipete: Introduced the current consolidated SecretRef grammar and validation module on main. (role: recent shared-contract contributor; confidence: high; commits: 1d84acf2c35b; files: src/secrets/ref-contract.ts)
• sallyom: Authored the merged Vault plugin and the public SDK target seam reused by this branch, establishing prior merged history beyond authoring this PR. (role: adjacent implementation author; confidence: high; commits: e595a8c0ac4b, 7b0471042feb; files: extensions/vault, src/plugin-sdk/secret-ref-runtime.ts)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

Review history (8 earlier review cycles)

• reviewed 2026-07-08T21:35:10.905Z sha 4fdd798 :: needs real behavior proof before merge. :: [P2] Support copyable 1Password references before using them as ids | [P2] Regenerate the docs map for the new plugin page
• reviewed 2026-07-08T21:43:31.834Z sha 4fdd798 :: needs real behavior proof before merge. :: [P2] Support copyable 1Password references before storing ids | [P2] Regenerate the docs map for the new plugin page | [P2] Fix the resolver lint errors | [P2] Remove the useless env spread fallback | [P2] Avoid the monolithic SDK literal in the test | [P2] Update the static asset baseline for the resolver asset
• reviewed 2026-07-08T22:10:41.434Z sha 4e15f24 :: found issues before merge. :: [P1] Move target resolution behind a public SDK seam | [P2] Regenerate the docs map for the new plugin page | [P2] Reject only Error instances from resolver spawn failures | [P2] Remove the redundant env spread fallback | [P2] Avoid the monolithic plugin SDK literal in the test
• reviewed 2026-07-09T23:35:15.550Z sha 7988dd2 :: found issues before merge. :: [P1] Use the current narrow SecretRef SDK helper | [P2] Avoid parallel per-id 1Password reads before bundling
• reviewed 2026-07-10T07:51:40.651Z sha ccdf464 :: found issues before merge. :: [P1] Remove the duplicate lockfile importer
• reviewed 2026-07-10T13:22:19.618Z sha 292efb4 :: found issues before merge. :: [P2] Bound the per-ID op read fanout | [P2] Make status honor custom provider aliases
• reviewed 2026-07-10T13:31:50.677Z sha 292efb4 :: found issues before merge. :: [P2] Bound the per-ID op read fanout | [P2] Make status honor custom provider aliases
• reviewed 2026-07-10T14:29:40.892Z sha f63830b :: found issues before merge. :: [P2] Bound the per-ID op read fanout | [P2] Make status honor custom provider aliases

[github-actions]

Dependency Guard

This PR changes dependency-related files. Maintainers should confirm these changes are intentional.

Changed files:

• extensions/1password/package.json
• pnpm-lock.yaml

Maintainer follow-up:

• Review whether the dependency changes are intentional.
• Inspect resolved package deltas when lockfile, shrinkwrap, or workspace dependency policy changes are present.
• Treat package-lock.json and npm-shrinkwrap.json diffs as security-review surfaces.
• Run pnpm deps:changes:report -- --base-ref origin/main --markdown /tmp/dependency-changes.md --json /tmp/dependency-changes.json locally for detailed release-style evidence.

[github-actions]

Dependency graph changes are blocked

OpenClaw does not accept dependency graph changes through PRs unless a repository admin or security explicitly authorizes the current head SHA. Dependency updates are generated internally by maintainers so external PRs cannot change the resolved graph.

Detected dependency graph changes:

• pnpm-lock.yaml changed.
• extensions/1password/package.json changed devDependencies, name, version.

Auto-scrub was not attempted because this PR changes package manifest dependency graph fields:

• extensions/1password/package.json changed devDependencies, name, version.

Dependency graph changes must be reviewed by security or handled by maintainers internally. Please remove lockfile changes manually if they are not needed.

To remove lockfile changes, restore them from the target branch:

git fetch origin
git checkout 'origin/main' -- 'pnpm-lock.yaml'
git commit -m 'chore: remove dependency lockfile change'
git push

If this PR intentionally needs a dependency graph change, ask a repository admin or member of @openclaw/openclaw-secops to comment:

/allow-dependencies-change

The action will approve the current head SHA (5b5971e2de5d48f05f79c7d5d58965e0396b1a53) when it reruns. A later push requires a fresh approval.