openclaw - 💡(How to fix) Fix mediaUnderstandingProviders audio path hard-requires API key, breaking no-auth/local STT providers [1 participants]

Summary

mediaUnderstandingProviders currently appear to be forced through provider API-key resolution in a way that breaks no-auth/local providers.

In practice, an audio/STT plugin can register a valid MediaUnderstandingProvider and work fine at the HTTP layer without any real API key, but OpenClaw still fails earlier with:

No API key found for provider "local-audio". Auth store ...

This makes some self-hosted / local / no-auth providers unusable for STT, even when the plugin itself does not require auth.

What I expected

If a provider plugin intentionally represents a local or no-auth service, OpenClaw should allow that provider to run without requiring auth-store credentials.

There are already related concepts in the plugin system such as:

• nonSecretAuthMarkers
• providerDiscoveryEntry
• local/self-hosted provider patterns used by bundled plugins like Ollama / LM Studio

I expected a provider plugin to be able to opt into a no-auth / dummy-auth path cleanly for media understanding, especially audio transcription.

What happens instead

The media-understanding audio path appears to resolve provider execution auth before invoking the plugin provider, and then hard-requires an API key.

The relevant runtime path seems to be roughly:

• media/audio execution
• resolveProviderExecutionAuth(...)
• resolveApiKeyForProvider(...)
• requireApiKey(...)

So even if the plugin's transcribeAudio(...) implementation is perfectly capable of talking to a local server with no auth, the request never reaches it.

Why this is a bug

This seems inconsistent with OpenClaw's broader plugin/provider architecture:

• a plugin can own a provider id
• a plugin can expose media understanding capability
• a plugin can represent a local/self-hosted provider
• but media STT still cannot run unless the core auth path is satisfied

That effectively means mediaUnderstandingProviders are not truly usable for no-auth providers unless they fake an API key and possibly also wire extra model-provider config that should not be necessary.

Minimal reproduction

1. Create a provider plugin that registers:
   • speechProviders: ["local-audio"]
   • mediaUnderstandingProviders: ["local-audio"]
2. Implement transcribeAudio(req) against a local OpenAI-compatible /audio/transcriptions endpoint that does not require auth.
3. Configure OpenClaw to use that provider for STT / media audio.
4. Send an audio/voice message that triggers transcription.

Result

OpenClaw fails before the request reaches the local service, with an error equivalent to:

No API key found for provider "local-audio". Auth store ...

Suggested fix

Any of these would solve the problem cleanly:

1. Allow media-understanding providers to declare no-auth execution explicitly
   • e.g. via plugin/provider metadata
2. Honor nonSecretAuthMarkers / provider discovery for media-understanding auth resolution
   • not just model-provider-style flows
3. Do not call requireApiKey(...) for providers that are explicitly local/no-auth
4. Pass through to transcribeAudio(...) with an empty or synthetic non-secret token when the provider is marked local/no-auth

Why this matters

This blocks legitimate local/self-hosted STT integrations, including OpenAI-compatible audio servers that intentionally do not require credentials on localhost.

OpenClaw already has a strong self-hosted/local story in other areas; this looks like one place where the media/STT auth assumptions are too strict.

Environment

Observed on OpenClaw 2026.4.22 and also investigated on 2026.4.26 while debugging a local audio provider plugin.

If useful, I can provide a minimal plugin example, but the core problem seems architectural rather than plugin-specific.