Bug: Image Uploads Can Permanently Brick Your Session When Vision Is Disabled

If you're using a model provider that doesn't support vision — or your organization has disabled vision capabilities — uploading an image to your OpenClaw session can trap you in an unrecoverable error loop. Here's what's happening and how a fix is on the way.

The Problem

When an image enters your session transcript (via webchat upload, tool result, or any other means) and your model can't process vision, OpenClaw enters a death spiral:

1. The image gets persisted in your transcript as a user turn
2. The model rejects the request with HTTP 400: "vision is not enabled for this organization"
3. No assistant reply gets saved (because of the error)
4. OpenClaw's pruneProcessedHistoryImages() function only strips images from turns before the last assistant reply — but since no assistant reply was saved, the image turn is never pruned
5. Every subsequent message re-sends the problematic image → another 400 error
6. The only escape is running /new or /reset

This affects anyone using GitHub Copilot models, enterprise deployments with vision disabled by policy, or any text-only model configuration without a fallback imageModel set.

Why This Happens

Two architectural issues combine to create the poison loop:

1. No vision-gating on transcript images: Even when OpenClaw detects that modelHasVision is false (the model resolves with input: ["text"] only), image blocks in the transcript are still sent to the provider. There's no step that strips image content from history when the model cannot handle it.

2. The pruning logic assumes success: The pruneProcessedHistoryImages() function in history-image-prune.ts only prunes images from turns that have already received an assistant response. If the image turn caused the failure — meaning no assistant reply was ever saved — it remains stuck after the last successful assistant turn and becomes a permanent poison pill.

The Fix

A community fix has been submitted in PR #29309. The solution is elegant: for text-only models, transcript image blocks are now pruned across all user history, including unanswered turns. This prevents the repeated HTTP 400 loop after a failed image request.

Workarounds Until the Fix Lands

• Configure an imageModel fallback for vision-capable analysis
• Use /new immediately after accidentally uploading an image
• Avoid image uploads entirely on text-only model configurations

If you're running a deployment where vision is disabled at the organizational level, keep an eye on PR #29309 or consider cherry-picking the fix early.

GitHub Issue: #29290