OpenClaw bug report draft: Telegram/OpenAI STT broken by runtime fetch FormData mismatch

Suggested title

[Bug]: multipart/FormData requests lose fields when fetchWithSsrFGuard routes through runtime undici fetch

Summary

Telegram voice-note auto transcription can fail even when OpenAI auth is configured correctly and manual transcription works.

Observed symptom in chat:

• inbound voice messages reach the agent only as [media attached: ... .ogg]
• no transcript is injected before the message hits the agent

Observed API failure when tracing the media/audio path:

• OpenAI returns HTTP 400: you must provide a model parameter

This is misleading at first glance because OpenClaw does resolve a default model (gpt-4o-transcribe) and manual fetch() / curl requests with the same file and key succeed.

Root cause

The failure is in the guarded HTTP path, not in Telegram or provider auth.

fetchWithSsrFGuard() uses fetchWithRuntimeDispatcher() whenever a dispatcher is active for SSRF-safe requests. That runtime path uses undici.fetch from OpenClaw's bundled runtime.

For audio transcription requests, the body is built with global FormData and then passed into that runtime undici.fetch path. Because the runtime fetch and the original body come from different FormData implementations/realms, multipart fields are not serialized correctly.

Result:

• the file may still be present enough for the request to parse
• but text fields like model are dropped or not encoded correctly
• OpenAI responds with you must provide a model parameter

Concrete repro

Environment:

• OpenClaw 2026.4.9
• Telegram inbound voice notes
• OpenAI auth profile present (openai:default)
• manual curl to /v1/audio/transcriptions works

This fails through the guarded/runtime fetch path:

const resWrap = await fetchWithSsrFGuard({
  url: 'https://api.openai.com/v1/audio/transcriptions',
  fetchImpl: fetch,
  init: {
    method: 'POST',
    headers: new Headers({ authorization: `Bearer ${apiKey}` }),
    body: form // global FormData
  },
  timeoutMs: 60000,
  dispatcherPolicy: { mode: 'direct' }
});

OpenAI response:

HTTP 400
{
  "error": {
    "message": "you must provide a model parameter"
  }
}

The same request works with plain global fetch() and also works with runtime undici.fetch() if the body is rebuilt using the runtime's own undici.FormData.

Fix

Before calling runtime undici.fetch, normalize FormData bodies into the runtime's own undici.FormData implementation and clear content-type / content-length so the multipart boundary is regenerated correctly.

Local patch that fixed it

File: dist/undici-runtime-C7foUhmW.js

• expose FormData from the bundled undici runtime deps

File: dist/fetch-guard-Conjfhmz.js

• add a normalization step in fetchWithRuntimeDispatcher()
• when init.body is FormData, rebuild it into runtimeDeps.FormData
• remove stale content-type and content-length headers before sending

Result after patch

• provider-level transcription succeeds
• media capability runner succeeds
• Telegram voice note arrives already transcribed in chat
• example successful inbound transcript:
  • Toto je poslední testovací zpráva.

Why this matters

This likely affects more than Telegram voice-note STT. Any guarded multipart request that goes through runtime undici.fetch may be vulnerable to the same FormData incompatibility.

That means this should probably be fixed centrally in the fetch/transport layer rather than only in the OpenAI audio transcription code path.

Suggested tests

Add regression coverage for:

1. guarded multipart POST with dispatcher enabled
2. global FormData body passed through runtime fetch path
3. OpenAI audio transcription request preserving both file and model
4. any other multipart provider flows that use the same guarded transport

Notes

Related symptom-level issues already existed around Telegram voice transcription, but this report identifies a lower-level transport root cause and a concrete fix.