openclaw - 💡(How to fix) Fix [Bug]: Image attachment send silently blocked after first successful image message in control UI

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

After sending one image attachment successfully in the webchat, all subsequent image sends are silently dropped — no console error, no network request, nothing reaches the gateway. Text-only messages continue to work fine.

Error Message

After sending one image attachment successfully in the webchat, all subsequent image sends are silently dropped — no console error, no network request, nothing reaches the gateway. Text-only messages continue to work fine. Actual: Message is dropped with no error in console, no network request made, no gateway log entry function Pp(e){return e.chatSending||!!e.chatRunId} is the send guard. chatRunId is set when a message is sent and only cleared when the server returns a final/aborted/error run state. After an image message completes, chatRunId is not being cleared — leaving the UI permanently in a "busy" state that silently blocks all subsequent image sends.

Root Cause

Root Cause (identified via source analysis of index-Dba6JFRP.js)

Fix Action

Workaround

Reload the page (Cmd+R) after each image send to reset chatRunId to null.

RAW_BUFFERClick to expand / collapse

Summary

After sending one image attachment successfully in the webchat, all subsequent image sends are silently dropped — no console error, no network request, nothing reaches the gateway. Text-only messages continue to work fine.

Steps to Reproduce

  1. Open chat at 127.0.0.1:18789
  2. Attach an image and send — succeeds
  3. Receive a response
  4. Attach another image and send — message silently disappears

Expected: Second image sends successfully Actual: Message is dropped with no error in console, no network request made, no gateway log entry

Root Cause (identified via source analysis of index-Dba6JFRP.js)

function Pp(e){return e.chatSending||!!e.chatRunId} is the send guard. chatRunId is set when a message is sent and only cleared when the server returns a final/aborted/error run state. After an image message completes, chatRunId is not being cleared — leaving the UI permanently in a "busy" state that silently blocks all subsequent image sends.

Workaround

Reload the page (Cmd+R) after each image send to reset chatRunId to null.

Environment

  • OpenClaw 2026.4.15 (041266a)
  • Chrome 147.0.0.0 on macOS
  • URL: 127.0.0.1:18789/chat?session=main

extent analysis

TL;DR

The issue can be temporarily resolved by reloading the page after each image send to reset the chatRunId state.

Guidance

  • The chatRunId is not being cleared after an image message is sent, causing the UI to remain in a "busy" state and block subsequent image sends.
  • To verify the issue, check the chatRunId value after sending an image and confirm it is not being reset.
  • A potential fix could involve modifying the Pp function to properly clear the chatRunId after a successful image send.
  • Consider adding error handling to detect and handle cases where the chatRunId is not being cleared correctly.

Example

function Pp(e){
  if (e.chatSending || !!e.chatRunId) {
    // Add logic to clear chatRunId after successful send
    if (/* send successful */) {
      e.chatRunId = null;
    }
    return true;
  }
  return false;
}

Notes

The provided workaround of reloading the page after each image send is temporary and may not be suitable for production use. A more permanent fix would involve modifying the underlying code to properly handle the chatRunId state.

Recommendation

Apply the workaround of reloading the page after each image send until a permanent fix can be implemented, as it allows for continued use of the chat functionality while a more robust solution is developed.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - 💡(How to fix) Fix [Bug]: Image attachment send silently blocked after first successful image message in control UI