Bug on FixClaw

Agent Timeout Does Not Display Error in Web UI - UI Hangs Indefinitely

Fri, 10 Apr 2026 00:00:00 +0000

Symptom

When an LLM request exceeds the agent timeout threshold, the following behavior is observed:

Gateway logs show ConnectionAbortedError: [WinError 10053] indicating the client aborted the connection
Agent logs correctly log the timeout with decision=surface_error reason=timeout
Web UI continues to display a loading spinner indefinitely
No error message is presented to the user
User cannot retry without manually refreshing the page, losing conversation context

The user expects to see a timeout error message and have the ability to retry, but instead the UI becomes unresponsive.

Root Cause Analysis

The investigation reveals that the root cause is a race condition in error event propagation:

When the agent detects an LLM timeout, it correctly identifies the timeout condition and decides to surface an error (decision=surface_error reason=timeout)
However, the agent’s timeout mechanism terminates the connection (causing ConnectionAbortedError) before the WebSocket can send the final event containing the status: "timeout" information
The Web UI client never receives the final event because the connection has already been terminated, leaving it in an indeterminate state showing a perpetual loading spinner
The custom gateway (ai_router.py) functions correctly with retry logic, but cannot compensate for the agent aborting the connection prematurely

The core issue is that the error status is logged but not communicated to the UI before the connection teardown occurs.

Solution

To resolve this issue, ensure that the final event with error status is always sent to the Web UI before or during connection teardown when a timeout occurs:

Modify the agent timeout handler to ensure the final event is flushed to the WebSocket before the connection is terminated
Wrap the error propagation in a try-finally block that guarantees the final event is sent even when the connection is being aborted: try: # timeout handling logic finally: # Ensure final event is sent before connection abort await send_final_event(status=“timeout”, error=“Agent request timed out”) # Then safely abort the connection
Add a timeout buffer that allows the final event to be delivered before the connection is forcibly closed
Verify WebSocket closure order - the final event should be sent and acknowledged before ConnectionAbortedError is raised

Code Location

The fix should be implemented in the agent’s timeout handling logic where the connection abort occurs, ensuring proper event sequencing.

Prevention

To prevent this issue from recurring:

Implement event-before-abort pattern: Always send status events before terminating connections in any error scenario, not just timeouts
Add integration tests: Create tests that verify the UI receives proper error events when agents timeout, specifically checking for final event delivery
WebSocket health checks: Add monitoring to detect when the UI is stuck in a loading state and automatically trigger recovery
Timeout handler review: Audit all timeout and abort code paths to ensure consistent error event propagation
Client-side timeout handling: Add a client-side timeout fallback in the Web UI that detects when no events have been received for a configured period and displays an appropriate message

Additional Information

Affected deployment: Docker deployment on Ubuntu-based container with Windows 11 host
Frequency: Intermittent - occurs when LLM response exceeds the 60-second agent timeout threshold
Workaround: Refresh the page (loses conversation context)
Related components:
- Agent timeout handler
- WebSocket event dispatcher
- Web UI state management

Sources

GitHub Issue #64793

TTS Voice Note Delivery Regression in v2026.4.9

Fri, 10 Apr 2026 00:00:00 +0000

Symptom

After upgrading to OpenClaw v2026.4.9, TTS (text-to-speech) voice note delivery is completely broken:

Outbound TTS (Voice Notes from Assistant):

User sends a text message to the assistant via Telegram
Assistant calls tts tool with channel: "telegram"
Tool returns Generated audio reply
Expected: Voice note delivered to user
Actual: Only text response received; no voice note

Inbound STT (Voice Notes to Assistant):

User sends a voice note to the assistant via Telegram
Expected: Audio transcribed and processed
Actual: No transcription; pdf tool fails with “Expected PDF but got audio/ogg”, image tool fails with “Unsupported media type: audio”

Evidence from logs:

Gateway logs show no TTS-related events after the tts tool call
No sendVoice API calls are made to Telegram
Text messages continue to work correctly (proving Telegram connectivity is intact)

Historical logs show the last sendVoice attempts failing: telegram sendVoice failed: Network request for ‘sendVoice’ failed! telegram final reply failed: HttpError: Network request for ‘sendVoice’ failed!

Root Cause Analysis

The investigation reveals that the tool→channel delivery handoff is broken:

ElevenLabs API is functioning correctly — Audio files are successfully generated by the tts tool
Tool reports success — Generated audio reply message confirms audio creation
Broken handoff — The audio file is never passed to the gateway’s Telegram channel
No sendVoice call — No Telegram API call is initiated to deliver the voice note
Regression introduced in v2026.4.9 — The change from pre-v2026.4.9 behavior (corrupted delivery) to v2026.4.9 (no delivery) indicates a code regression in how the tts tool result is handled by the channel delivery layer

Pre-v2026.4.9 behavior: TTS generated audio but it was corrupted (appearing as long strings of exclamation marks in webchat).

v2026.4.9 behavior: TTS generates audio but delivers nothing at all.

The shift from “corrupted delivery” to “no delivery” suggests the audio file handling code path was either removed or broken during the v2026.4.9 update.

Solution

This is a code regression bug that requires a fix in the OpenClaw codebase. The following steps are needed:

Restore the sendVoice call path in the channel delivery layer — Ensure the audio file generated by the tts tool is properly passed to sendVoice for Telegram delivery
Verify audio file handling — Confirm the audio file path/content is correctly transferred between the tool result handler and the Telegram sender
Add integration tests for TTS→Telegram delivery to prevent future regressions
Fix STT handling — Ensure inbound voice notes are properly recognized and routed to the STT pipeline instead of being rejected as unsupported media types

Temporary Workaround:

Users may attempt to use the message tool with explicit media path for file attachment (untested)

Prevention

To prevent similar regressions in future releases:

Add automated TTS integration tests — Create end-to-end tests that verify voice notes are actually delivered to Telegram (not just that the tool reports success)
Test the full delivery pipeline — Ensure both generation AND delivery are tested together, not in isolation
Monitor channel delivery layer changes — Any modifications to how tool results are processed should include regression testing for media delivery
Log delivery confirmation — Add explicit logging when sendVoice is called to make failures more visible in logs
Multi-channel testing — Test TTS functionality when multiple channels (Telegram + webchat) are active simultaneously, as session handling issues may compound the problem

Additional Information

Affected versions: OpenClaw v2026.4.9 (updated 2026-04-09) and potentially later versions
Previous working behavior: Pre-v2026.4.9 had corrupted audio delivery
TTS Provider tested: ElevenLabs (eleven_multilingual_v2)
Channel: Telegram
Network connectivity: Confirmed working (text messages deliver successfully)
API credentials: ElevenLabs credentials verified functional via manual API calls
Multi-session factor: Session handling issues may contribute when Telegram and webchat are used simultaneously

Sources

GitHub Issue #64272

Slack requireMention: true Bypassed for Thread Replies After Prior Bot Participation

Wed, 25 Mar 2026 00:00:00 +0000

Symptom

When OpenClaw is configured with requireMention: true for a Slack channel, the bot still responds to messages in a thread that do not mention the bot, after the bot has previously participated in that same thread.

Reproduction Steps:

Configure a Slack channel with requireMention: true
Start a thread and explicitly mention the OpenClaw bot in the first message (or any reply)
Observe OpenClaw replies as expected
Send another reply in the same thread without mentioning the bot
Unexpected behavior: OpenClaw may still reply, despite requireMention: true being set

Impact:

Bot generates unnecessary noise in Slack threads
Responds on behalf of others without being explicitly requested
Breaks user expectation that the bot only responds when tagged

Root Cause Analysis

The issue stems from how OpenClaw’s Slack integration handles implicit mentions in threaded conversations.

Technical Flow

Thread Participation Tracking: When OpenClaw delivers a reply in a thread, it records the thread participation: if (anyReplyDelivered && participationThreadTs) recordSlackThreadParticipation(account.accountId, message.channel, participationThreadTs);
Implicit Mention Calculation: For subsequent messages in that thread, OpenClaw checks if the bot has participated: const implicitMention = Boolean( !isDirectMessage && ctx.botUserId && message.thread_ts && ( message.parent_user_id === ctx.botUserId || hasSlackThreadParticipation(account.accountId, message.channel, message.thread_ts) ) );
Mention Gating Logic: The implicitMention flag is passed to the mention gating resolver: const mentionGate = resolveMentionGatingWithBypass({ isGroup: isRoom, requireMention: Boolean(shouldRequireMention), canDetectMention, wasMentioned, implicitMention, … });
Effective Mention Decision: The gating function treats implicitMention as equivalent to being mentioned: function resolveMentionGating(params) { const implicit = params.implicitMention === true; const bypass = params.shouldBypassMention === true; const effectiveWasMentioned = params.wasMentioned || implicit || bypass; return { effectiveWasMentioned, shouldSkip: params.requireMention && params.canDetectMention && !effectiveWasMentioned }; }

Root Cause

The core problem is that prior thread participation is treated as an implicit mention, which effectively bypasses the requireMention: true configuration. Once OpenClaw has replied in a thread, subsequent messages in that thread will always trigger responses, regardless of whether the bot is mentioned.

Solution

Immediate Workaround

Until this bug is fixed in a future release, consider the following workarounds:

Use Separate Threads for Bot Interactions:
- Start a new thread when you want to interact with OpenClaw
- Avoid replying in threads where the bot has already participated
Temporarily Disable Thread Replies:
- If frequent in-thread discussions occur without wanting bot participation, manually archive or close threads
Adjust requireMention at the Cost of Usability:
- Setting requireMention: false globally will allow all messages to trigger responses (not recommended as a long-term solution)

Code-Level Fix (For Developers)

The fix should modify the Slack integration to respect requireMention: true regardless of thread participation. In the resolveMentionGating function, the logic should be updated so that when requireMention is explicitly true, only explicit mentions are accepted:

function resolveMentionGating(params) { const implicit = params.implicitMention === true; const bypass = params.shouldBypassMention === true;

// When requireMention is true, implicit mentions should not bypass the check
const effectiveWasMentioned = params.wasMentioned || (params.requireMention ? false : (implicit || bypass));

return {
    effectiveWasMentioned,
    shouldSkip: params.requireMention && params.canDetectMention && !effectiveWasMentioned
};

}

Alternatively, the implicitMention calculation could be modified to not consider thread participation when requireMention is enabled for the channel.

Prevention

To prevent unexpected behavior until this bug is fixed:

Review Thread Usage:
- Be aware that bot participation in a thread may cause unintended future replies
- Use direct messages for isolated bot interactions
Monitor Bot Responses:
- Keep an eye on channels with requireMention: true for unexpected bot behavior
- Report any instances of the bot responding to untagged messages
Stay Updated:
- Monitor the GitHub issue for fixes and updates
- Apply patches promptly when they become available
Documentation:
- Document this known limitation for team members using the Slack integration
- Include workarounds in internal runbooks

Additional Information

Affected Versions: OpenClaw 2026.3.23-2 (and likely earlier versions)
Platform: Amazon Linux 2023.10.20260302
Install Method: npm global
Model: openai/gpt-5.4

The bug is classified as a behavior bug rather than a crash, as it produces incorrect output without causing system failure. The severity is “Annoying” with frequency rated as “Each time.”

File	Purpose
`/runtime-api-BI9wNO54.js`	Main Slack integration runtime
`hasSlackThreadParticipation()`	Checks if bot participated in thread
`recordSlackThreadParticipation()`	Records bot participation in thread
`resolveMentionGating()`	Determines if bot should respond

Sources

GitHub Issue #64277

Bug on FixClaw

Agent Timeout Does Not Display Error in Web UI - UI Hangs Indefinitely

Symptom

Root Cause Analysis

Solution

Code Location

Prevention

Additional Information

Sources

TTS Voice Note Delivery Regression in v2026.4.9

Symptom

Root Cause Analysis

Solution

Prevention

Additional Information

Sources

Slack requireMention: true Bypassed for Thread Replies After Prior Bot Participation

Symptom

Root Cause Analysis

Technical Flow

Root Cause

Solution

Immediate Workaround

Code-Level Fix (For Developers)

Prevention

Additional Information

Related Code Locations

Sources