openclaw - 💡(How to fix) Fix [Bug]: googlemeet join/create fails on exec:onepassword SecretRef at plugin register() — beta.8 — blocks all realtime modes

Bug type

Behavior bug / regression (unresolved SecretRef in realtime/voice paths blocks Google Meet realtime entirely)

Summary

The openclaw googlemeet join, openclaw googlemeet create, and the gateway-tool google_meet.join paths all fail to resolve exec:onepassword:op://... SecretRefs at command time when those refs back voice-call or google-meet realtime config paths. The error consistently surfaces as:

plugins.entries.voice-call.config.<...>.providers.<openai|google>.apiKey: unresolved SecretRef "exec:onepassword:op://<vault>/<id>/<field>". Resolve this command against an active gateway runtime snapshot before reading it.

This affects realtime-voice testing on OpenClaw 2026.5.12-beta.8 (commit 097daf9). openclaw googlemeet status works (read-only path), but any path that triggers plugin register() — including realtime session attachment — fails because plugin loading reads raw config refs before resolveCommandSecretRefsViaGateway() runs.

This appears to be the same loader-order issue documented in #57272 and the realtime-specific failure documented in #72120. PR #72126 (the proposed fix for #72120) was closed unmerged. The bug persists in beta.8.

Environment

• OpenClaw version: 2026.5.12-beta.8 (097daf9)
• OS: macOS 26 Tahoe, Apple Silicon (Mac mini)
• Node: v25.5.0
• Install: npm install -g [email protected]
• Auth: 1Password service account via OP_SERVICE_ACCOUNT_TOKEN env var (set in gateway env-wrapper, verified in ps eww)
• SecretRef format used throughout: {"source": "exec", "provider": "onepassword", "id": "op://Vault/Item/field"}

Reproduction

1. Configure plugins.entries.voice-call.config.realtime.providers.google.apiKey with an exec:onepassword:op://... SecretRef
2. Configure plugins.entries.google-meet.config.realtime.providers.google.apiKey similarly
3. Set google-meet realtime to canonical bidi mode:

   "plugins.entries.google-meet.config.realtime": {
     "strategy": "bidi",
     "voiceProvider": "google",
     "transcriptionProvider": "openai",
     "model": "gemini-2.5-flash-native-audio-preview-12-2025",
     "agentId": "<agent>",
     "toolPolicy": "safe-read-only",
     "providers": { "google": { "apiKey": <SecretRef>, "voice": "Kore" }, "openai": { "apiKey": <SecretRef> } }
   }

4. Kickstart gateway (gateway snapshot resolves SecretRefs successfully here — confirmed via env vars present in process)
5. Attempt: openclaw googlemeet join "https://meet.google.com/<code>" --transport chrome-node --mode realtime

Expected

Join proceeds. Realtime session attaches. openclaw googlemeet status --json shows sessions: non-empty.

Actual

CLI immediately bails:

[openclaw] Could not start the CLI.
[openclaw] Reason: plugins.entries.voice-call.config.realtime.providers.google.apiKey: unresolved SecretRef "exec:onepassword:op://OpenChachi/<id>/credential". Resolve this command against an active gateway runtime snapshot before reading it.

Chrome-level Meet tab opens (in some paths), but sessions: array remains empty — no realtime bridge attached. Meet participants see the bot present but silent/deaf.

Note: the error path label is misleading. It says plugins.entries.voice-call.config.streaming.providers.openai.apiKey even when voice-call has been removed from openclaw.json entirely. The actual unresolved SecretRef may be at models.providers.openai.apiKey or plugins.entries.google-meet.config.realtime.providers.openai.apiKey — the error formatter has a hardcoded label that doesn't reflect the actual offending path.

Workarounds attempted (none worked)

What does work

• openclaw googlemeet status (read-only, doesn't trigger plugin register())
• openclaw googlemeet join --mode transcribe (observe-only, bypasses realtime stack — confirmed working today and used as workaround for meeting note-taking)
• All non-realtime googlemeet operations

Logs

Gateway runtime resolves the SAME SecretRefs successfully at startup (snapshot built cleanly). The failure is at command-time on plugin register(). Sample log evidence:

2026-05-14T09:00:40.591-05:00 [ws] ⇄ res ✗ googlemeet.join 2522ms errorCode=UNAVAILABLE 
  errorMessage=plugins.entries.voice-call.config.streaming.providers.openai.apiKey: 
  unresolved SecretRef "exec:onepassword:op://OpenChachi/<id>/password". 
  Resolve this command against an active gateway runtime snapshot before reading it.

Related issues

• #57272 (open) — "openclaw status fails on file-backed SecretRef configs because route/plugin loading re-reads unresolved raw config" — same loader-order root cause class
• #72120 (closed as superseded) — "OpenAI Realtime browser session sends unresolved keychain SecretRef as API key" — same realtime-path symptom, different SecretRef source format
• #72126 (closed unmerged) — "fix(openai): resolve keychain refs for realtime API keys" — would have addressed the realtime path; never landed
• #80288 (closed not-planned) — "Codex app-server isolated HOME breaks trusted local tool auth; add real-home override" — adjacent secrets/isolation work that was deliberately not fixed

Suggested fix direction

Per #57272's analysis: move resolveCommandSecretRefsViaGateway() to run BEFORE loader.ts:loadOpenClawPlugins() so plugin register() sees resolved secrets. The same fix appears to be needed for the realtime tool surface paths (googlemeet.join, googlemeet.create, google_meet.join tool).

Alternatively: have the CLI proxy realtime tool calls to the gateway (which already has resolved snapshot) instead of locally re-loading plugins.

Severity

High for any operator trying to use Google Meet realtime mode. Forces fallback to observe-only/transcribe-mode joins, which loses bidirectional voice capability entirely.