Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Bug] User image attachments dropped when primary model lacks vision — imageModel fallback not honored [1 participants]

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…
GitHub stats
openclaw/openclaw#68513•Fetched 2026-04-19 15:10:44
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
0
Author
WwNeXstWwNeXst
Participants
WwNeXstWwNeXst
Timeline (top)
cross-referenced ×1

Root Cause

File: `attachment-normalize-fsjzmyqL.js`

`parseMessageWithAttachments` uses `supportsImages` resolved from the primary model only. It does not check or fall back to `agents.defaults.imageModel`.

The `imageModel` config is only used for tool-generated images (via the `agents/tool-images` subsystem), not for user-sent attachments.

Fix Action

Workaround

Manual model switch to a vision-capable model (Kimi K2.5) before each screenshot, then switch back.

RAW_BUFFERClick to expand / collapse

Bug Description

User-sent image attachments (e.g., screenshots dragged into webchat) are dropped at the gateway layer when the primary model does not support image input, even when `agents.defaults.imageModel` is configured.

Steps to Reproduce

  1. Set primary model to MiniMax M2.7 Highspeed (`input: ["text"]`)
  2. Configure `agents.defaults.imageModel.primary` to `moonshot/kimi-k2.5` (supports vision)
  3. Drag and drop a screenshot into webchat and send
  4. Observe in gateway logs: `parseMessageWithAttachments: 1 attachment(s) dropped — model does not support images`
  5. Image never reaches the model layer; `imageModel` fallback is never triggered

Root Cause

File: `attachment-normalize-fsjzmyqL.js`

`parseMessageWithAttachments` uses `supportsImages` resolved from the primary model only. It does not check or fall back to `agents.defaults.imageModel`.

The `imageModel` config is only used for tool-generated images (via the `agents/tool-images` subsystem), not for user-sent attachments.

Expected Behavior

User-sent image attachments should be treated the same as tool-generated images: when the primary model cannot accept images, the message should be routed to the model specified in `imageModel` instead of being silently dropped.

Workaround

Manual model switch to a vision-capable model (Kimi K2.5) before each screenshot, then switch back.

Environment

  • OpenClaw: 2026.4.15
  • macOS
  • Primary model: minimax/m2.7-highspeed
  • Fallback imageModel: moonshot/kimi-k2.5

extent analysis

TL;DR

Modify the parseMessageWithAttachments function in attachment-normalize-fsjzmyqL.js to check and fall back to agents.defaults.imageModel when the primary model does not support images.

Guidance

  • Update the parseMessageWithAttachments function to resolve supportsImages from both the primary model and agents.defaults.imageModel.
  • Verify the fix by checking gateway logs for successful image attachment processing when the primary model does not support images.
  • Consider adding a feature flag or configuration option to enable the fallback behavior for user-sent image attachments.
  • Review the agents/tool-images subsystem to ensure consistency in image handling between tool-generated and user-sent images.

Example

// Pseudo-code example, actual implementation may vary
function parseMessageWithAttachments(message) {
  const primaryModelSupportsImages = primaryModel.supportsImages;
  const imageModelSupportsImages = agents.defaults.imageModel.supportsImages;
  
  if (!primaryModelSupportsImages && imageModelSupportsImages) {
    // Route message to imageModel
  }
}

Notes

The provided workaround of manually switching models is not scalable and may not be feasible for all users. A permanent fix should be implemented to ensure consistent image handling.

Recommendation

Apply workaround: Manually switch to a vision-capable model before sending image attachments, as this provides a temporary solution until the parseMessageWithAttachments function can be updated.

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…
#api#ssr#installation#tensor shape#request timeout

Still need to ship something?

×6

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

Back to top recommendations

TRENDING