claude-code - 💡(How to fix) Fix Oversized images in resumed conversations should auto-downscale instead of hard-blocking the turn [1 comments, 2 participants]

Summary

When a Claude Code session accumulates an image larger than the API's per-image dimension limit (~2000px on a side) in its conversation history — typically from a screenshot tool, an MCP image server's output, or an inline [photo] attachment — every subsequent turn returns a hard error:

An image in the conversation exceeds the dimension limit for many-image requests (2000px). 
Run /compact to remove old images from context, or start a new session.

The session is otherwise alive (TUI rendering, plugin polling, network healthy) but cannot make a single API call. The only recovery path is /compact (which uses tokens to summarize the entire history) or /clear (which throws away context). For long-running sessions resumed via --resume, this is a real cliff: a single oversized screenshot from days ago can permanently brick the session until manually compacted.

We're hitting this 4+ times per day across multiple long-running sessions on Claude Code 2.1.122 (macOS + Linux, both via --continue and --resume).

Repro

1. Start a Claude Code session in a project that has an MCP server which returns images (e.g., XcodeBuildMCP screenshots, nano-banana, browser tools).
2. Take a screenshot or generate an image with any axis ≥ 2001px (a Retina mac screenshot is ~3024×1964, very close to the limit; some Android emulator screenshots exceed it).
3. Continue the conversation for a few more turns — image stays in history.
4. Eventually, hit a turn where the API consolidates the image batch and rejects it.
5. From that point on, every prompt errors with the message above. TUI is alive, plugin still polls, but no model call can succeed.

Expected

Either:

• Auto-downscale at injection time: when an image returned by a tool/MCP exceeds 2000px on either axis, Claude Code resizes it (Lanczos resampling, preserve aspect ratio) before injecting into the message history. Original full-res can stay on disk if the caller needs it.
• Auto-strip on conflict: when an API call fails with the dimension-limit error, Claude Code transparently retries by either dropping or downsizing the offending image, instead of surfacing a hard wall to the user.
• At minimum, a config flag (maxImageDimension or similar) so users can opt into auto-downscale globally.

Actual

Hard error, session unusable until /compact runs. For sessions driven by a Telegram bot or other automation, the user has no way to even know the session is stuck — it just stops replying.

Why it matters

• Long-running sessions resumed via --resume accumulate old screenshots over days; the cliff is invisible until it lands.
• Telegram-channel-driven workflows (--channels plugin:telegram@claude-plugins-official) have no way to surface the error to the user — the bot silently stops responding.
• Operator workaround (manual /compact) costs tokens AND interrupts whatever was in flight.

Environment

• Claude Code: 2.1.122 (Linux + macOS, multiple machines)
• Sessions: long-running, resumed daily via --resume, frequently process screenshots from XcodeBuildMCP / chrome-devtools / nano-banana / tmux capture-pane style tools.

Workarounds we're using

• Detect the error string in tmux pane output via an external monitor and auto-fire /compact.
• Considered building a downscale wrapper around tool outputs but feels like Claude Code's job, not ours.

Happy to provide more diagnostic data if useful.