Bug type

Regression (worked before, now fails)

Beta release blocker

Yes (silent loss of inbound voice-call functionality whenever realtime.provider is a plugin that isn't already loaded)

Summary

In 2026.5.7, enabling voice-call.realtime with provider: "openai" (and OpenAI not auto-loaded for other reasons) causes the voice-call runtime to fail with:

[voice-call] Failed to start runtime: Realtime voice provider "openai" is not registered

The voice-call plugin's runtime initializes at gateway startup. At that point the bundled openai plugin has activation.onStartup: false and has not been loaded — so its realtimeVoiceProviders contract is not in the active runtime registry. The capability resolver in resolvePluginCapabilityProviders does not eagerly load the missing provider plugin in this case, and resolveConfiguredRealtimeVoiceProvider throws missing-configured-provider.

This is functionally the same shape of failure as #60936 (closed by #61224), but on the realtime voice code path instead of the realtime transcription path. PR #61224 made the webhook server use fullConfig for transcription provider resolution; the realtime voice resolver appears to have the same root cause (capability lookup at startup before the provider plugin has loaded) and the existing fix doesn't cover it.

Steps to reproduce

1. Fresh install of [email protected] on macOS.
2. Configure voice-call for Twilio + ngrok with realtime enabled:

   {
     "plugins": {
       "allow": ["voice-call", "openai", "memory-core", "google", "xai"],
       "entries": {
         "openai": { "enabled": true },
         "voice-call": {
           "enabled": true,
           "config": {
             "provider": "twilio",
             "twilio": { "accountSid": "...", "authToken": "..." },
             "fromNumber": "+1XXXXXXXXXX",
             "inboundPolicy": "open",
             "tunnel": { "provider": "ngrok" },
             "realtime": {
               "enabled": true,
               "provider": "openai",
               "providers": {
                 "openai": { "apiKey": "sk-proj-...", "model": "gpt-4o-realtime-preview" }
               }
             }
           }
         }
       }
     }
   }

3. Agent's primary model is xai/grok-4 (no OpenAI model in catalog, so OpenAI is not auto-enabled by the model-driven path).
4. openclaw gateway restart
5. Place a call to the Twilio number.

Expected behavior

Inbound call connects to OpenAI realtime voice and the agent responds.

Actual behavior

• Gateway startup log: http server listening (3 plugins: google, memory-core, voice-call; ...)
• Error log: [voice-call] Failed to start runtime: Realtime voice provider "openai" is not registered
• Inbound call returns just <Pause length="30"/> TwiML → 30 seconds of dead air → Twilio gives up.
• openclaw voicecall setup reports OK for all checks including mode: Realtime voice enabled (openai), because that probe is purely config-validity and doesn't query the active runtime registry. So voicecall setup does not surface the failure.

OpenClaw version

2026.5.7

Operating system

macOS 26.3.1 (arm64), Node 22.14.0

Install method

pnpm (global install at /usr/local/.../node_modules/openclaw)

Model

xAI Grok-4 as the agent's primary model; OpenAI used only for realtime voice.

Provider / routing chain

twilio -> ngrok -> openclaw/voice-call -> openai realtime

Additional provider/model setup details

openai plugin is enabled-in-config and present in plugins.allow. Its manifest declares activation.onStartup: false and contracts.realtimeVoiceProviders: ["openai"].

Logs, screenshots, and evidence

Trace-level gateway log around startup:

[plugins] loading google from .../extensions/google/index.js
[plugins] loading memory-core from .../extensions/memory-core/index.js
[plugins] loading voice-call from ~/.openclaw/npm/.../voice-call/dist/index.js
[plugins] loaded 3 plugin(s) (3 attempted) in 1170.0ms
[gateway] http server listening (3 plugins: google, memory-core, voice-call; 1.7s)
[plugins] [voice-call] Failed to start runtime: Realtime voice provider "openai" is not registered

Note: 3 plugins attempted — the openai plugin is never even attempted at startup, despite being enabled in config and present in plugins.allow. google and memory-core are attempted because: memory-core is the memory slot (so it's eager); google provides memoryEmbeddingProviders: ["gemini"] which the memory boot path needs; voice-call's manifest has activation.onStartup: true. openai and xai only declare contracts (realtime-voice, text-inference, etc.) and have onStartup: false, so they're not in the eager-load set.

Workaround

Patch the bundled openai plugin manifest to set activation.onStartup: true:

python3 - <<'PY'
import json
p = '/path/to/openclaw/dist/extensions/openai/openclaw.plugin.json'
d = json.load(open(p))
d['activation']['onStartup'] = True
json.dump(d, open(p, 'w'), indent=2)
PY

After this, gateway startup shows 4 plugins: google, memory-core, openai, voice-call and [voice-call] Realtime voice provider: openai — works.

This survives until the next openclaw update, after which it must be re-applied.

Root cause (proposed)

When the voice-call plugin's runtime initializes and realtime.enabled is true, resolveConfiguredRealtimeVoiceProvider calls into resolvePluginCapabilityProviders({ key: "realtimeVoiceProviders", cfg }) in dist/capability-provider-runtime-*.js. With getLoadedRuntimePluginRegistry() already populated (google has loaded), activeProviders is non-empty ([google]) but missingRequestedProviders is {"openai"} after the active filter. The fallback path then calls resolveCachedCapabilityProviderEntries → loadCapabilityProviderEntries, which does getLoadedRuntimePluginRegistry() again and short-circuits to loadedEntries (which is [google]) without attempting to cold-load openai from disk — because cold-loading (resolveRuntimePluginRegistry) only runs when the loaded registry is null:

const coldEntries = (loadedRegistry ? void 0 : resolveRuntimePluginRegistry(params.loadOptions))?.[params.key] ?? [];

So once any plugin is loaded, subsequent capability lookups for plugins that haven't been loaded yet won't dynamically pull them in.

Impact and severity

Affected: anyone using voice-call realtime with a provider plugin (openai, in practice) whose manifest doesn't have onStartup: true and isn't otherwise eagerly loaded. Severity: High (total loss of inbound realtime voice; misleading voicecall setup output). Frequency: 100% reproducible on a clean install.

Possible fixes

1. Targeted: when voice-call.config.realtime.enabled is true, ensure the configured provider's plugin (realtimeVoiceProviders contract) is loaded before voice-call's runtime initializes. Could be done in the loader's pre-startup phase by walking voice-call's needed-contract set, or in voice-call's register() by declaring a dependency.
2. General: in loadCapabilityProviderEntries, when loadedRegistry is non-null but is missing requested providers, also run the cold-load path for the missing ones (rather than short-circuiting).
3. Stop-gap: add activation.onStartup: true to the bundled provider plugins that own realtimeVoiceProviders / realtimeTranscriptionProviders contracts (openai, google). Simple, but means openai always runs even when only used for realtime voice.