Summary

Telegram/audio transcription can unexpectedly use a local Whisper CLI even when an API provider is configured/available, and Groq OpenAI-compatible audio transcription can fail when OpenClaw passes a proxy-wrapped fetch into the audio provider.

Local reproduction

Environment:

• macOS gateway
• tools.media.audio.models configured with provider: "groq", model: "whisper-large-v3"
• GROQ_API_KEY set
• HTTP_PROXY / HTTPS_PROXY set
• /opt/homebrew/bin/whisper present

Observed behavior:

1. In the audio auto path, resolveAutoEntries() checks local audio CLIs before resolveKeyEntry(), so an installed local whisper/whisper-cli can win over API-provider transcription.
2. After forcing the provider path to Groq, the request failed with:

Audio transcription failed (HTTP 400): {"error":{"message":"request Content-Type isn't multipart/form-data","type":"invalid_request_error"}}

Raw curl to https://api.groq.com/openai/v1/audio/transcriptions with the same key/audio file succeeded, and calling the OpenAI-compatible audio provider directly without the proxy-wrapped fetchFn also succeeded.

Expected behavior

If an audio API provider is configured or available via provider key, OpenClaw should prefer that provider before auto-detecting local CLIs. For OpenAI-compatible audio uploads, multipart form requests should not be broken by an EnvHttpProxyAgent fetch wrapper; the shared provider HTTP helper already has URL-aware proxy/NO_PROXY handling.

Proposed fix

• In audio resolveAutoEntries(), try resolveKeyEntry() before local CLI fallback.
• For audio provider entries, do not pass resolveProxyFetchFromEnv() directly; let provider HTTP helpers handle proxy env and NO_PROXY at request time.
• Add regression coverage for provider-key priority when a local whisper binary exists, and for audio proxy fetch behavior.

I have a small patch ready with focused Vitest coverage.