openclaw - ✅(Solved) Fix Regression: Screenshot/image upload broken in webchat on 2026.4.15 [1 pull requests]

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…

Image/screenshot uploads via the webchat Control UI stopped working after upgrading from 2026.4.5 to 2026.4.15. The attachment button is present in the UI but images do not arrive in the agent session — the agent receives only the text message with no image attached.

Root Cause

Image/screenshot uploads via the webchat Control UI stopped working after upgrading from 2026.4.5 to 2026.4.15. The attachment button is present in the UI but images do not arrive in the agent session — the agent receives only the text message with no image attached.

Fix Action

Workaround

Downgraded back to 2026.4.5 — screenshots work again immediately after downgrade + gateway restart.

PR fix notes

PR #69474: fix(gateway): restore webchat pure-image turn handling (#69358)

Description (problem / solution / changelog)

Summary

Fixes #69358 Fixes #69415 Fixes #69427

get-reply-run.ts now checks baseBodyForPrompt.trim() (which includes the inbound-context prefix) instead of baseBodyFinal.trim() for the empty-turn gate, and falls back to the plain "[User sent media without caption]" placeholder only when the entire prompt body is empty. This restores pure-image webchat turns that were bailing out with "I didn't receive any text in your message. Please resend or add a caption." (English) / "不可发送空消息" (localized same payload).

Root Cause

  1. Webchat images arrive through replyOptions.images and — by explicit project design — do not stamp sessionCtx.MediaPath (see src/gateway/server-methods/chat.directive-tags.test.ts:1697-1698, which asserts ctx.MediaPath stays undefined on dispatch).
  2. Commit eb10803691 ("fix(prompt): keep inbound chat ids out of system prefix") tightened the reply-run empty-turn gate from baseBodyForPrompt.trim() to baseBodyFinal.trim().length > 0 (i.e. the strict user body, prefix excluded).
  3. The same commit also changed effectiveBaseBody so the "[User sent media without caption]" placeholder is always appended on top of inboundUserContext when there is no user body, instead of being used only as a last-resort fallback.
  4. For a pure-image webchat turn: hasUserBody === false (no caption), hasMediaAttachment === false (no ctx.MediaPath) → the gate returns the empty-message payload and the image never reaches the vision model. When a caption is present, the placeholder text leaks into the Control UI user bubble on top of the Sender-metadata prefix.

All three issues are the same regression, reported from different angles:

  • #69358 — pure-image Control UI send returns the empty-message error payload.
  • #69415 — same behavior reported against the Web UI (localized message text).
  • #69427 — screenshot/image upload broken after upgrading from 2026.4.5 → 2026.4.15 (the release that shipped eb10803691).

The Fix

Revert the three src/auto-reply/reply/get-reply-run.ts hunks introduced by eb10803691 back to the stable 2026.4.5 behavior:

  • gate: baseBodyTrimmed = baseBodyForPrompt.trim() so the normal webchat inbound-context prefix keeps the run alive;
  • effectiveBaseBody = baseBodyTrimmed ? baseBodyForPrompt : "[User sent media without caption]" so the placeholder is only used when there is truly nothing else, never appended on top of a non-empty prefix.

Also drops the media-only regression added by eb10803691 for the metadata-only-prefix bail-out — it encoded exactly the behavior this PR reverts.

Testing

This fix addresses the case where pure-image webchat (Control UI) sends were showing:

  • agent reply "I didn't receive any text in your message. Please resend or add a caption." / "不可发送空消息" instead of a vision-model response;
  • placeholder text [User sent media without caption] in the Control UI user bubble on top of the Sender-metadata prefix when a caption was supplied.

Verified locally:

  • pnpm check:changed --staged — scoped typecheck + lint + guards + tests pass
  • pnpm tsgo — core prod typecheck green
  • pnpm test src/auto-reply/reply/get-reply-run.media-only.test.ts — 26/26 pass
  • Manual repro in the Control UI (webchat): pure image + no caption → agent describes the image, user bubble renders the uploaded image.

Checklist

  • Code changes are minimal and targeted (revert of three hunks in a single file + obsolete test removal)
  • Fix addresses the root cause identified in #69358 / #69415 / #69427
  • Commit message references the issue number

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/auto-reply/reply/get-reply-run.media-only.test.ts (modified, +43/-0)
  • src/auto-reply/reply/get-reply-run.ts (modified, +4/-6)

Code Example

2026-04-20T13:21:18 [ws] webchat connected conn=... client=openclaw-control-ui webchat v2026.4.15
2026-04-20T13:25:44 [ws] webchat disconnected code=1001 reason=n/a
RAW_BUFFERClick to expand / collapse

Bug Report

Version: 2026.4.15 (041266a) Previous working version: 2026.4.5 Platform: macOS 26.2 (arm64), Node 22.22.1 Channel: webchat (Control UI)

Description

Image/screenshot uploads via the webchat Control UI stopped working after upgrading from 2026.4.5 to 2026.4.15. The attachment button is present in the UI but images do not arrive in the agent session — the agent receives only the text message with no image attached.

Steps to Reproduce

  1. Upgrade to 2026.4.15 via npm install -g [email protected]
  2. Open the webchat Control UI
  3. Attach a screenshot or image file using the attachment button
  4. Send the message
  5. Agent receives only text — no image content

Expected Behavior

Image is received and processed by the agent (as it worked in 2026.4.5).

Gateway Logs

Gateway logs show the webchat connection established and disconnected cleanly (code=1001) but no [agents/tool-images] Image resized to fit limits entries appear for the upload attempt (those entries were present in earlier sessions from the same day under 2026.4.5).

2026-04-20T13:21:18 [ws] webchat connected conn=... client=openclaw-control-ui webchat v2026.4.15
2026-04-20T13:25:44 [ws] webchat disconnected code=1001 reason=n/a

Workaround

Downgraded back to 2026.4.5 — screenshots work again immediately after downgrade + gateway restart.

Notes

  • Hard refresh of Control UI (Cmd+Shift+R) + new session did not resolve
  • Potentially related to the Gateway/tools fix in 2026.4.15 that anchors trusted local MEDIA: passthrough and rejects client tool definitions that collide with built-ins
  • Also possibly related to webchat audio embedding path containment fix (Gateway/webchat: enforce localRoots containment on webchat audio embedding path)

extent analysis

TL;DR

The issue with image uploads via the webchat Control UI after upgrading to version 2026.4.15 can likely be resolved by reverting the changes related to the Gateway/tools fix and webchat audio embedding path containment in the 2026.4.15 version.

Guidance

  • Review the Gateway/tools fix that anchors trusted local MEDIA: passthrough and rejects client tool definitions that collide with built-ins, as it may be causing the issue with image uploads.
  • Investigate the webchat audio embedding path containment fix (Gateway/webchat: enforce localRoots containment on webchat audio embedding path) to see if it's related to the problem.
  • Check the gateway logs for any errors or warnings related to image uploads or the Gateway/tools fix.
  • Consider downgrading to version 2026.4.5 as a temporary workaround, as it has been reported to resolve the issue.

Example

No code snippet is provided as the issue is more related to configuration and version changes.

Notes

The exact cause of the issue is not clear, but it seems to be related to changes introduced in version 2026.4.15. Further investigation is needed to determine the root cause and find a permanent solution.

Recommendation

Apply workaround: Downgrade to version 2026.4.5, as it has been reported to resolve the issue, until a permanent fix is available.

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