openclaw - 💡(How to fix) Fix Secret broker plugin: first-class `secret.get`/`secret.has` over Bitwarden / Keychain / 1Password / Vault [2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#74759Fetched 2026-05-01 05:41:40
View on GitHub
Comments
2
Participants
2
Timeline
9
Reactions
2
Author
Timeline (top)
mentioned ×3subscribed ×3commented ×2cross-referenced ×1

Add a generic "secret broker" plugin so agents can resolve named secrets at call time without copy-pasting them into chat or env files.

Root Cause

Add a generic "secret broker" plugin so agents can resolve named secrets at call time without copy-pasting them into chat or env files.

Code Example

secret.get({ name, field? })            // returns value (never stored in transcript)
secret.has({ name })                    // existence check
secret.list({ prefix? })                // names only, never values

---

{
  "secrets": {
    "backend": "bitwarden",  // or "1password" | "keychain" | "vault"
    "bitwarden": { "broker": "~/bin/bw-get.sh" },
    "keychain":  { "service": "openclaw" }
  }
}
RAW_BUFFERClick to expand / collapse

Summary

Add a generic "secret broker" plugin so agents can resolve named secrets at call time without copy-pasting them into chat or env files.

Why

OpenClaw runs as a 24/7 personal agent. Side projects (Slack bots, GitHub PR runners, fast-flights scraper, etc.) all need credentials, and the user shouldn't have to paste them. Today the workflow is:

  • User stashes credentials in Bitwarden (or 1Password, or macOS Keychain) once.
  • A local broker script (~/bin/bw-get.sh in this setup) fetches them on demand: ~/bin/bw-get.sh <item> [field].
  • Every project that needs a secret has to call that shell script — which works, but isn't a first-class OpenClaw concept and isn't portable across hosts.

Proposed surface

A pluggable resolver under mcp__openclaw__secret_*:

secret.get({ name, field? })            // returns value (never stored in transcript)
secret.has({ name })                    // existence check
secret.list({ prefix? })                // names only, never values

With a config block selecting the backend:

{
  "secrets": {
    "backend": "bitwarden",  // or "1password" | "keychain" | "vault"
    "bitwarden": { "broker": "~/bin/bw-get.sh" },
    "keychain":  { "service": "openclaw" }
  }
}

Backends start with the two that already work in practice on this machine:

  1. Bitwarden (wraps an existing broker script — bw-get.sh-style)
  2. macOS Keychain (security find-generic-password -s <name> -w)

Important constraints

  • Never write secrets to disk beyond what the backend itself does.
  • Redact in transcripts — values returned from secret.get should be tagged so transcript dumps replace them with [REDACTED:<name>].
  • Scope guard — refuse to return secrets when the active session is a group chat or has untrusted participants (configurable allowlist of session kinds).

Related

Filed alongside #74757 and #74758 — same root motivation (let the agent do real host work without bouncing back to the user for every small step).

extent analysis

TL;DR

Implement a pluggable secret resolver with a configurable backend to securely manage secrets without exposing them in chat or environment files.

Guidance

  • Define a secrets configuration block with a selected backend (e.g., Bitwarden, 1Password, or Keychain) and relevant settings.
  • Implement the secret.get, secret.has, and secret.list functions to interact with the chosen backend, ensuring secrets are never written to disk and are redacted in transcripts.
  • Develop a scope guard to restrict secret access based on session type and participant trustworthiness.
  • Consider starting with Bitwarden and macOS Keychain backends, as they are already functional on the machine.

Example

{
  "secrets": {
    "backend": "bitwarden",
    "bitwarden": { "broker": "~/bin/bw-get.sh" }
  }
}

Notes

The implementation should prioritize security and adhere to the constraints outlined, such as never writing secrets to disk and redacting them in transcripts.

Recommendation

Apply a workaround by implementing the proposed pluggable secret resolver with a configurable backend, as it addresses the root motivation of securely managing secrets without exposing them.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - 💡(How to fix) Fix Secret broker plugin: first-class `secret.get`/`secret.has` over Bitwarden / Keychain / 1Password / Vault [2 comments, 2 participants]