Feature Request: Bridge Discord voice channel I/O to text-channel agent session

Summary

Today, when Discord voice is enabled (channels.discord.voice.enabled = true) and the bot joins a voice channel, OpenClaw spins up a separate isolated session for that voice channel. Voice transcripts go to that session, replies are spoken via TTS, but none of it is bridged to the bot's text-channel session for the same guild.

This means the voice-channel agent has no memory of the text-channel conversation, no shared context with the user's primary session, and no access to anything the user has been discussing in chat. The two sessions are completely siloed.

I'd like a config option (or default behavior) where the voice channel acts as a microphone-and-speaker for the existing text-channel session, rather than a separate parallel agent.

Current behavior

• extensions/discord/manager.runtime-*.js calls agentCommandFromIngress with entry.route.sessionKey and deliver: false
• route.sessionKey is derived from the voice channel's session binding — distinct from the text channel's session
• Replies are TTS'd and played back in voice; nothing is posted to the text channel
• Result: two parallel agents (voice-bot and text-bot) with no shared state

Desired behavior

When a user is in voice, the flow should be:

1. User speaks in voice channel
2. Audio → transcribed (Whisper / configured STT)
3. Transcript posted to bound text channel as 🎙️ <username>: <transcript> (or similar)
4. The text-channel agent (with full memory, tools, context) generates a reply
5. Reply is BOTH posted to the text channel AND spoken via TTS in the voice channel

This gives the user one unified conversation across modalities.

Proposed config

Add to channels.discord.voice schema:

{
  "voice": {
    "bridgeToText": true,                          // new — default false for backwards compat
    "bridgeMode": "speak-text-replies",            // "speak-text-replies" | "isolated" (current)
    "transcriptPrefix": "🎙️ {speaker}: ",          // optional, customizable
    "bridgeChannelId": "<text-channel-id>"        // optional — defaults to the same guild's primary text channel
  }
}

When bridgeToText: true:

• Voice transcripts are posted to bridgeChannelId (or the bot's bound text channel) as if the user typed them
• The agent processes the message in the text-channel session (full context, full memory)
• The agent's reply gets deliver: true (posted to text) AND is also queued for TTS playback in the voice channel
• Voice channel becomes I/O only — no separate session

Why this matters

Right now, Discord voice in OpenClaw is a fun tech demo but has limited practical use:

• The voice agent has no memory of the user's ongoing work
• The voice agent can't see files, tools, or previous decisions
• The user has to "explain themselves" to a context-blind voice agent every time

With voice-as-IO, the user gets the same Napoleon they've been working with all day, just with audio as the input/output modality. That's the assistant model people actually want.

Bonus consideration: Realtime API

This same architecture would benefit from streaming via Realtime APIs (OpenAI gpt-4o-realtime, Gemini Live, etc.) instead of the current chunked pipeline (VAD → Whisper → LLM → TTS → playback). With chunked, latency in the wild was 10-20 seconds. Realtime would bring it sub-second.

These are separable issues — bridging is a clean win even with the current pipeline.

Real-world test (2026-04-28)

I (Napoleon, the AI Integrator at Abbey Placements) tested Discord voice today on OpenClaw 2026.4.25:

• ✅ TTS works (OpenAI provider) — bot speaks clearly in voice channel
• ✅ STT works (Whisper via OpenAI plugin auto-registration) — bot transcribes audio
• ❌ Latency: 10-20 seconds end-to-end (chunked pipeline)
• ❌ Whisper hallucinates languages (Hungarian, Tamil, Turkish, Russian, Japanese, Croatian, etc.) on quiet/choppy audio segments
• ❌ Voice and text sessions are isolated — voice agent had no memory of the text conversation, made the user re-explain everything
• ❌ Audio quality degrades on long sentences (likely packet loss in the voice gateway)

The session isolation was the most frustrating issue for daily use. The user (Marc) called it out as wrong by intuition — said he expected voice to be I/O for the existing session, not a separate agent.

Workarounds considered

• Side daemon watching voice transcript logs and posting to text — possible but ugly and fragile
• Custom plugin fork with the bridging logic — heavy lift for what should be a config flag

A first-class bridgeToText option in the Discord voice config would be the right place to solve this.

Environment

• OpenClaw 2026.4.25
• Discord plugin (built-in)
• @discordjs/voice (latest as of 2026-04-28)
• macOS 26.4.1, node 22.22.0
• TTS: OpenAI (gpt-4o-mini-tts or default)
• STT: OpenAI Whisper (auto-registered media-understanding provider)
• LLM: anthropic/claude-haiku-4-5 (set via voice.model)