Summary
On OpenClaw 2026.4.9, the infer audio transcribe / STT CLI path fails for OpenAI audio transcription even though the provider returns a valid transcript.
In the failing path, the user sees the transcription treated as empty / missing (No transcript returned), but a direct call to OpenAI's official /v1/audio/transcriptions endpoint with the same audio succeeds and returns the expected text.
Observed behavior
- Same audio file succeeds when sent directly to OpenAI official audio transcription API.
- OpenClaw STT CLI path fails to surface the transcript.
- Result is effectively handled as
No transcript returned.
Verified transcript returned directly by OpenAI:
{"text":"帮我调研一下,现在亚马逊的服务器或者其他的主流的云服务器厂商有这种可以关机之后就不计费的这种高性能显存的服务器套餐或者是服务吗?"}
Why this seems distinct from transport-level provider failures
This does not appear to be:
- bad audio
- unsupported format
- provider outage
- OpenAI inability to transcribe the sample
The provider returns a valid payload. The likely bug is in OpenClaw's integration/parsing layer for the OpenAI transcription response on this CLI/STT path.
Likely root cause
OpenClaw's OpenAI audio transcription adapter or post-processing logic appears to incorrectly parse or extract the returned transcript from the provider response for this code path, causing a valid result to be treated as empty.
Expected behavior
If the provider returns a successful JSON response such as:
OpenClaw should surface that transcript instead of falling back to `No transcript returned`.
## Actual behavior
OpenClaw discards or fails to extract the transcript and reports no transcript.
## Environment
- OpenClaw version: 2026.4.9
- Provider tested: OpenAI official audio transcription API
- Failure path: OpenClaw STT / `infer audio transcribe`
- Control path: direct OpenAI `/v1/audio/transcriptions` call succeeds
## Notes
There are already related audio transcription issues around multipart / provider integration, but this report is specifically about a successful OpenAI response not being surfaced to the user on the current CLI path.
Summary
On OpenClaw 2026.4.9, the
infer audio transcribe/ STT CLI path fails for OpenAI audio transcription even though the provider returns a valid transcript.In the failing path, the user sees the transcription treated as empty / missing (
No transcript returned), but a direct call to OpenAI's official/v1/audio/transcriptionsendpoint with the same audio succeeds and returns the expected text.Observed behavior
No transcript returned.Verified transcript returned directly by OpenAI:
{"text":"帮我调研一下,现在亚马逊的服务器或者其他的主流的云服务器厂商有这种可以关机之后就不计费的这种高性能显存的服务器套餐或者是服务吗?"}Why this seems distinct from transport-level provider failures
This does not appear to be:
The provider returns a valid payload. The likely bug is in OpenClaw's integration/parsing layer for the OpenAI transcription response on this CLI/STT path.
Likely root cause
OpenClaw's OpenAI audio transcription adapter or post-processing logic appears to incorrectly parse or extract the returned transcript from the provider response for this code path, causing a valid result to be treated as empty.
Expected behavior
If the provider returns a successful JSON response such as:
{"text":"..."}