openclaw - 💡(How to fix) Fix [Bug]: Talk mode can speak a different answer than the Control UI when agent reply uses message_tool_only / delivery-mirror [1 pull requests]

Summary

Control UI Talk mode can speak a different answer than the final answer displayed in the chat UI.

In a live repro, the realtime voice response said it could not get the requested information, while the Control UI displayed a successful final answer with the correct tool call result.

Environment

• OpenClaw version: 2026.5.20 (e510042)
• Surface: Control UI Talk
• Session shape: named agent main session
• Talk provider: OpenAI Realtime
• Realtime model: gpt-realtime-2
• Transport: webrtc
• Talk brain path: openclaw_agent_consult
• Agent model: openai-codex/gpt-5.5
• Install/runtime: macOS gateway, npm global install

Reproduction

1. Open the Control UI chat for an agent session.
2. Start Talk mode using OpenAI Realtime / gpt-realtime-2.
3. Ask a question that requires the agent to call tools and then deliver through the message tool.
4. Listen to the spoken response.
5. Compare it with the visible final chat response.

Observed behavior

The agent run succeeded and the UI showed the correct final answer, including the expected tool-backed result:

The agent successfully retrieved the requested information from a tool and displayed the correct final answer in the Control UI.

The spoken response, however, said that it could not get the information.

Local evidence

The local transcript for the affected turn shows a successful tool-backed agent run and a correct visible final answer. The relevant run id was:

talk-call_S3Ud0oZogFA8B6DW-f7525890-bb37-4bfc-8e0c-e52e65a81b74

The transcript sequence shows:

• the Talk-originated prompt was submitted to the agent;
• the agent called a shell/tool-backed status check;
• the status check returned the correct tool call data;
• the agent sent the correct answer through the message tool;
• the message tool result included:
  • sourceReplyDeliveryMode: "message_tool_only"
  • sourceReplySink: "internal-ui"
• the Control UI then displayed the same answer through a mirrored assistant message:
  • provider: openclaw
  • model: delivery-mirror

This suggests the Control UI text path and the Talk audio path did not share one canonical final-answer source.

Expected behavior

Talk mode should speak the same final answer that the Control UI displays.

If the agent consult path produces a user-visible answer through message_tool_only / delivery-mirror, the Talk bridge should use that canonical answer as the spoken response, or suppress/revise any realtime improvised fallback.

Possible fix directions:

1. Return sourceReply.text from message_tool_only deliveries to the realtime openclaw_agent_consult tool result.
2. For Talk-originated turns, prefer plain final assistant text over a message-tool-only delivery path when the target is the current Control UI run.
3. Delay speech until the canonical final response is available, and avoid speaking an unrelated fallback when the consult run completed successfully.

Impact

This breaks user trust in Talk mode because the user can hear one answer while the screen shows another. It is especially risky for personal-assistant workflows where voice is the primary interaction surface.

Related issues

Possibly adjacent, but not exact duplicates:

• #59150: delivery-mirror / reply integrity after tool sends
• #79055: realtime voice lifecycle/context hook

I searched for existing issues involving openclaw_agent_consult, message_tool_only, delivery-mirror, and Talk mode, and did not find this exact voice/UI divergence case.