Oversized image (>2000px) poisons all later image processing in a session — misleading error + token waste

Environment: Claude Code (VSCode extension), model Opus 4.8 (1M context)

Summary

Once a single image exceeding 2000px on a side enters a conversation, every subsequent image input — including valid ones well under 2000px — is rejected with:

could not process this image (At least one of the image dimensions exceed max allowed size for many-image requests: 2000 pixels)

The error is attributed to the new image, but the actual offender is an earlier image still in the conversation context. There is no recovery within the session.

Repro

1. Add an image larger than 2000px on a side (e.g. a 1633×6445 PNG read from disk, or a 2818px-wide pasted screenshot).
2. Continue the chat, adding several more images (crossing the "many images" threshold).
3. Upload or read a new image comfortably under 2000px (e.g. 1440×1146).

➡️ The small, valid image is rejected with the 2000px "many-image requests" error.

Observed inconsistency

Within the same session, some 2818px-wide images were silently downscaled and accepted (surfaced as displayed at 2000x1072), while others — and all later small ones — were rejected outright. So auto-downscaling clearly can happen, but does not happen reliably.

Expected

Either:

• auto-downscale oversized images (as already happens inconsistently), or
• reject only the offending image rather than poisoning the whole request and all subsequent valid images;

and in the error, identify which image is oversized.

Actual

A single earlier oversized image makes image processing fail for the rest of the session; valid small images can no longer be viewed; the error is misleading; and the rejected requests still consume input tokens (compounded by client/agent retries, since the error says "do not retry" but recovery is attempted anyway).

Impact

Image-based workflows break mid-session with no fix except starting a brand-new conversation, and tokens are wasted on rejected image requests.