openclaw - 💡(How to fix) Fix [Bug]: WebChat images fail with 400 Param Incorrect for non-vision models — image model routing receives incompatible format

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

When a non-vision model (DeepSeek V4 Pro, DeepSeek V4 Flash, GLM-5.1) receives an image via WebChat, the image model routing fails with 400 Error from provider (Xiaomi): Param Incorrect and failoverReason: "format". The image file is successfully offloaded to media/inbound/ by the gateway, but the format passed to the image model via the channel pipeline is incompatible. The error also occurs with Kimi K2.6 as the image model (not just Xiaomi Omni). Telegram and subagent (direct Omni) work correctly with the same image. This is a regression from v2026.5.7 where WebChat images worked without workarounds.

Steps to reproduce

1. Configure OpenClaw with a non-vision model as the primary agent model (e.g., custom-api-deepseek-com/deepseek-v4-pro, opencode-go/deepseek-v4-flash, ollama-cloud/glm-5.1:cloud)
2. Ensure image model is configured (tested: opencode-go/mimo-v2-omni and moonshot/kimi-k2.6 — BOTH affected)
3. Send an image via WebChat
4. Observe the agent does not see the image — it sees "image omitted: model does not support images"
5. Check gateway logs: [gateway] Offloaded attachment (image/png). Saved: media://inbound/... followed by 400 Error from provider: Param Incorrect with failoverReason: "format", providerRuntimeFailureKind: "schema"

Expected behavior

The image model should receive the image and process it, allowing the non-vision primary model to include the visual analysis in its response — as observed on v2026.5.7 where WebChat images worked correctly through image model routing without workarounds. This also works correctly today via Telegram and subagent direct calls.

Actual behavior

Gateway log excerpt:

19:23:02 [gateway] Offloaded attachment (image/png). Saved: media://inbound/image---7b77eb34-e9a1-432a-9890-ca05166585b5.png
...
400 Error from provider (Xiaomi): Param Incorrect
failoverReason: "format"
providerRuntimeFailureKind: "schema"
candidate_failed, next=none
Embedded agent failed before reply

The non-vision model never receives the image analysis. The agent sees only "image omitted: model does not support images" with no visual context. This was tested and consistently reproducible on both v2026.5.18 and v2026.5.20. The tools.media.image pipeline (configured per ClawDocs) was also tested and produces the same 400 Param Incorrect error.

OpenClaw version

2026.5.20 (e510042) — also reproduced on 2026.5.18 (50a2481)

Operating system

Windows 11 (10.0.26200 x64)

Install method

npm global

Model

Primary: custom-api-deepseek-com/deepseek-v4-pro, opencode-go/deepseek-v4-flash, ollama-cloud/glm-5.1:cloud (all non-vision) | Image models tested: opencode-go/mimo-v2-omni, moonshot/kimi-k2.6 (both affected)

Provider / routing chain

WebChat channel → OpenClaw gateway → opencode-go → Xiaomi Omni (image model routing)

Additional provider/model setup details

Image models tested (BOTH affected by this bug):

• Provider: opencode-go, Model: mimo-v2-omni, Timeout: 300s
• Provider: moonshot, Model: kimi-k2.6, Timeout: 300s

Primary agent models tested (all non-vision, all affected):

• custom-api-deepseek-com/deepseek-v4-pro
• opencode-go/deepseek-v4-flash
• ollama-cloud/glm-5.1:cloud

Vision model as PRIMARY agent (NOT affected — receives image directly in prompt):

• moonshot/kimi-k2.6

The tools.media.image pipeline was tested (per ClawDocs docs) and does NOT fix this issue — same 400 Param Incorrect error.

Last known good version: v2026.5.7 — WebChat images routed correctly through image models without workarounds.

Logs, screenshots, and evidence

Gateway log (redacted — success vs failure comparison):

✅ Telegram image (WORKS):
19:28:24 [telegram] Inbound message telegram:8681671742 -> @centralpc_openclaw_bot (direct, image/jpeg)
19:29:44 [telegram] outbound send ok accountId=default chatId=8681671742

✅ Subagent Omni direct call (WORKS):
model_call:success duration=39000ms model=opencode-go/mimo-v2-omni

❌ WebChat image (FAILS):
[gateway] Offloaded attachment (image/png). Saved: media://inbound/image---xxx.png
[ws] ⇄ res ✗ chat.send 461ms
failoverReason: "format"
providerRuntimeFailureKind: "schema"
400 Error from provider (Xiaomi): Param Incorrect
candidate_failed, reason=format, next=none
Embedded agent failed before reply

❌ tools.media.image pipeline (FAILS — same error):
Image resized (1335x664px, 763KB -> 59KB, -92.3%)
400 Error from provider (Xiaomi): Param Incorrect
failover: candidate_failed, reason=format, next=none

Impact and severity

Affected: All WebChat users with non-vision primary models who need image understanding via image model routing. Severity: Moderate — blocks image understanding in WebChat channel. Agents cannot analyze images without manual workaround. Frequency: 100% (every WebChat image with non-vision model). Consequence: Non-vision model agents in WebChat are effectively blind to images. The workaround (manual Get-ChildItem + image tool) works but requires the agent to implement it explicitly, which is fragile and non-obvious.

Additional information

Workaround found

Images are correctly saved to ~\.openclaw\media\inbound\ by the gateway. The workaround is to bypass the channel's image routing entirely:

1. Get-ChildItem 'C:\Users\centr\.openclaw\media\inbound' | Sort-Object LastWriteTime -Descending
2. Call image tool directly on the inbound file path (no workspace copy needed — the image tool accepts media/inbound paths)

This was tested and works on both WebChat and Telegram for non-vision models.

Differential diagnosis

Key insight: The same image file, processed by the same image model, works when called via direct tool call but fails when routed through the WebChat channel's image pipeline. This affects multiple image models (MiMo-V2-Omni AND Kimi K2.6), suggesting a channel-level format mismatch, not a provider-specific issue.

Regression

• Last known good: v2026.5.7 — WebChat images routed correctly through image models, no workaround needed
• First known bad: v2026.5.18
• Current: v2026.5.20 (e510042) — still affected