2000px many-image cap locks session permanently — fires on text-only prompts, /compact unreachable

Bug: 2000px many-image dimension cap locks session permanently — fires on text-only prompts, /compact workaround unreachable

Filed by: George Samuelson (@georgesamuelson)
Date drafted: 2026-04-26
Target: https://github.com/anthropics/claude-code/issues

---

Summary

The "many-image dimension limit (2000px)" error fires repeatedly on every prompt in a session once triggered, including text-only prompts with no image attached. The suggested workaround (/compact) cannot be executed because the model can't generate any response — every input returns the same error. The session becomes permanently unusable; the only recourse is to abandon it.

This appears to be a regression. Cmd+Shift+4 region screenshots dragged into Claude Code worked reliably for months prior; in recent versions the same workflow now triggers the cap on conversations that previously accepted them.

Environment

• Claude Code version: 2.1.119
• Platform: macOS Darwin 25.4.0
• Display: Retina (Cmd+Shift+4 captures at 2× pixel density)
• Image source: Mac native screenshots (Cmd+Shift+4 region grab)

Verbatim Error Message

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.

Reproduction

1. Begin a Claude Code session and accumulate several screenshots over the course of work (e.g., 4-6 region grabs dragged into the chat)
2. Continue working text-only for some time (no new images added)
3. Leave the session idle for ~5-6 hours (laptop locked / overnight)
4. Resume the session and send any input — text prompt, slash command, or new attachment

Result: Every input returns the identical "exceeds the dimension limit for many-image requests (2000px)" error. Even prompts with zero image content ("continue", "Can you give me the piece to copy and paste again?") trigger the error.

Two Distinct Issues

Issue 1 — Retroactive cap evaluation against text-only prompts

The error fires on prompts that contain no image at all. Example sequence from a captured session log:

❯ continue                                                          → ERROR
❯ Can you give me the piece to copy and paste again?                → ERROR
❯ there's no image, so this has to be a caching thing               → ERROR
❯ [skill load: /transcript]                                         → ERROR

The user is not attaching anything new — the cap is re-evaluating accumulated conversation history against a per-image dimension threshold and refusing to process the text-only request. The expected behavior would be to either (a) drop the offending historical image from the active context window automatically, or (b) at minimum allow text prompts and slash commands (especially /compact) to execute.

Issue 2 — /compact workaround is unreachable from the locked state

The error message instructs the user to "Run /compact to remove old images from context, or start a new session." However, /compact itself cannot execute because the model never produces output — the request is blocked before any tool/slash invocation can run. The only escape is "start a new session," which discards all in-progress work.

This is a UX dead-end. The error proposes a fix the user cannot apply.

Possible root cause (speculation)

Behavior pattern suggests the session re-validates accumulated images against the many-image threshold on resume after long idle periods. Images that fit when originally attached (single-image cap, e.g., 8000px) are then evaluated against the lower many-image cap (2000px) once the conversation crosses some image-count threshold. Retina display screenshots routinely exceed 2000px on a side; a "near-fullscreen" Cmd+Shift+4 grab on a 5K display can be 4000-5000px wide.

Trigger Sensitivity

Per session log, the user's prior pattern was:

• Take Cmd+Shift+4 region screenshots
• Drag-drop directly into Claude Code
• This worked reliably for months

In recent versions, the same screenshots now trigger the cap immediately on drop, without the conversation needing to accumulate other images first. The behavior changed; user workflow did not.

Expected Behavior

1. Accumulating large screenshots in a conversation should not retroactively block text-only prompts.
2. If the many-image cap is genuinely hit, Claude Code should automatically downscale historical images to fit — or strip the oldest images from active context — rather than refusing all input.
3. The user-recommended workaround (/compact) must be reachable from the locked state. At minimum, slash commands should bypass the image-validation gate.
4. Drag-and-drop screenshot UX should warn users approaching the dimension cap before acceptance, not after acceptance + later retroactive failure.

Actual Behavior

Session becomes permanently unusable. User must abandon work and start a new session. There is no graceful degradation path.

Severity

High — this is a complete loss of session continuity for a common workflow (Mac users with Retina displays taking screenshots and dragging them into Claude Code). The user lost ~20 minutes of attempted recovery before realizing the session was unrecoverable, plus all the implicit context built up in the conversation.

Additional Context

• Claude Code's drag-and-drop accepts the screenshot at the time of drop — no preview warning, no dimension validation surface to the user
• The error message itself is the only place where the 2000px many-image limit is documented (no docs surfaced through /help or in the drag-and-drop UX)
• Workaround attempts the user tried, all failed: typing /compact (blocked by error), retry with text-only prompt (blocked), waiting and retrying (blocked deterministically across 20+ minutes)
• Pre-validation tooling for users (sips -g pixelWidth -g pixelHeight <screenshot>) exists but is not surfaced — most Mac users won't think to check pixel dimensions before dragging

Suggested Fix Directions

In rough order of impact:

1. Slash commands bypass the image-validation gate. /compact, /clear, /help should always execute regardless of conversation image state. Without this, the error message is asking the user to do something they cannot do.
2. Auto-downscale on retroactive cap trigger. If the conversation crosses the many-image threshold, Claude Code should automatically downscale the offending historical images server-side rather than refusing all input.
3. Pre-validation at drop time. Drag-and-drop should display a non-blocking warning when an image is approaching the many-image cap, so the user can decide to downscale before accepting.
4. Document the cap. Add the 2000px many-image threshold to /help output and the drag-and-drop docs. Users should be able to discover this without hitting the error.
5. Improve the error message. If the workaround is unreachable, don't suggest it. At minimum say: "Cannot recover this session — image cap exceeded. Start a new session and use sips --resampleWidth 1600 input.png --out output.png to pre-resize screenshots before dropping."

---

Forensic Trail (for Anthropic engineers)

Session log excerpts captured in:

• ~/Projects/ea-jorts/sessions/md/ea-jorts-session-333-9f65d285-20260426-1057-detailed.md (entire ❯/⏺ interaction sequence at lines containing "2000px")
• Screenshots in user's Downloads folder dated 2026-04-26 between 10:25 AM and 10:54 AM ET (Cmd+Shift+4 region grabs at Retina density, file sizes 4-4.7 MB)

The user did not get the error on the screenshots while they were originally being attached during active work. The error only manifested after a ~5-hour idle gap, supporting the "retroactive re-validation on resume" hypothesis.