Agent creates an audio file but will not attach it in a Discord DM

Adapted community discussion: Translated, paraphrased, and condensed from an anonymized public OpenClaw Discord support conversation from August 2026. Technical guidance was reviewed for OpenClaw 2026.9.3.

My agent created a small WAV file, but in a Discord direct message it says the chat interface cannot send multimedia attachments. The same kind of request worked in a private server before. I already have FFmpeg installed. Is the direct message the problem?

Discord DMs support attachments, and FFmpeg only creates or converts media. It does not upload the file. The likely issues are tool permission and file visibility. The agent needs the message tool, and the final file path must be readable from the Gateway, not only from an isolated subagent or container. Check the tool list in that same DM session.

The agent tries a music-generation tool, refers to an example path, then reports Media failed.

The agent is missing the tools that can deliver or generate media. Keep the coding profile and extend it for the relevant agent:

{
  tools: {
    profile: "coding",
    alsoAllow: ["message", "tts"],
  },
}

Validate the config and open a fresh session before checking the tool list again.

My config already has the coding profile, cross-context message settings, and inbound audio transcription through Whisper.

Those settings do different jobs. Inbound transcription does not synthesize speech, and cross-context settings do not grant the message tool. Once message and tts appear, test with /tts status. For the existing WAV, ask the agent to attach the real Gateway-visible path through message, not a placeholder path.

I already had a Google TTS voice configured. Why is the agent asking for a Talk voice instead?

Talk and one-off TTS are separate surfaces. In OpenClaw 2026.9.3, TTS configuration lives under top-level tts. Keep tts.auto off so normal replies remain text; explicit speech requests and /tts audio <text> can still produce audio. Store provider credentials through the supported secret flow, never directly in a public config excerpt.