openclaw - 💡(How to fix) Fix [Bug]: `messages.tts` silently hangs at `tool:tts:started` when provider=elevenlabs (direct curl works — routing layer is the bug)

Summary

When messages.tts is configured with provider elevenlabs, calls to the TTS tool get stuck at tool:tts:started and never produce a tool:tts:completed event. The session hangs, the user never gets audio, and the only signal is the missing completion event.

A direct curl to the ElevenLabs API with the same key/voice/text returns 200 with audio bytes immediately, so the failure is in the OpenClaw routing/plugin layer, not at the provider.

Reproduce

1. Configure messages.tts.provider = elevenlabs, valid apiKey, valid voiceId.
2. Trigger any TTS (e.g. agent finishes a turn that requests TTS reply).
3. Observe: tool:tts:started fires; no tool:tts:completed; the run eventually times out.
4. Run the equivalent curl -X POST https://api.elevenlabs.io/v1/text-to-speech/<voiceId> -H "xi-api-key: …" -d '{"text":"…"}' from the same host with the same key — returns 200, MP3 audio bytes.

Expected

TTS request reaches ElevenLabs and the response stream is forwarded back; tool:tts:completed fires.

Actual

The plugin appears to hang internally without surfacing an error. No retry, no timeout, no log line indicating the upstream request was even attempted.

Why this matters

TTS reply is a fallback channel for voice-mode users. With this hang, the user has no signal that their request failed.

Environment

OpenClaw 2026.5.7 (eeef486); macOS; messages.tts plugin.

Suggestion

Add a per-request timeout in the elevenlabs branch of the routing layer, plus an error log line when the upstream HTTP call fails or never starts. A simple curl runner inside the plugin would already reveal the failure point.