[BUG] An image in the conversation exceeds the dimension limit for many-image requests (2000px). Start a new session with fewer images.

Same issue here. Running Claude Code v2.1.88 on Linux (Debian) with Opus 4.6.

This happens frequently in longer sessions where screenshots are taken (e.g. using browser automation MCP tools for web development). After a few screenshots accumulate in context, the session becomes unusable with:

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.

Problems:

• /compact doesn't reliably fix it — the oversized images often persist in context after compaction
• There's no way to selectively remove specific images from context
• The session is effectively bricked, forcing a new session and losing all conversation context
• Images taken by MCP tools (screenshots) shouldn't be allowed into context at dimensions that will break the session later

Expected behavior:

• Claude Code should auto-resize images to within limits before adding them to context
• Or at minimum, provide a command to drop specific images (e.g. /drop-image 3) without losing the rest of the conversation
• /compact should strip all images from context as a recovery mechanism

Same shit. Does everyone at Anthropic use low-resolution screens?

<img width="1154" height="342" alt="Image" src="https://github.com/user-attachments/assets/34551e99-ce8c-4286-addc-ad8b843a02e9" />

<img width="414" height="298" alt="Image" src="https://github.com/user-attachments/assets/c83f1a62-694f-430e-bf54-95e1998badca" />

have had this happen multiple times on multiple platforms. Including Mac OS

Surely this isnt that hard to fix. The main challenge seems to be retina display using the chrome extension or chrome dev tools because they dont set the pixels like playwright does.

Two workarounds for anyone hitting this on macOS while waiting for a real fix.

Option A — ask Claude Code to build the hook for you. Paste this prompt:

We hit the 2000px image limit. Write a permanent PreToolUse hook for Read that uses sips to downsample any image over 2000px to max 1440px before it's read. Wire it into ~/.claude/settings.json. Include escape hatches for filenames with _full / _original / _raw and paths under /raw/ or /original/. Smoke test it against a synthetic 3000px PNG and confirm it resizes cleanly.

It'll write the script, wire it up, and run a smoke test. About 2 minutes.

Option B — drop in the ready-made script.

~/.claude/hooks/resize-oversized-image.sh:

#!/usr/bin/env bash
set -euo pipefail
input=$(cat)
[[ "$(printf '%s' "$input" | jq -r '.tool_name // empty')" != "Read" ]] && exit 0
file=$(printf '%s' "$input" | jq -r '.tool_input.file_path // empty')
[[ -z "$file" || ! -f "$file" ]] && exit 0
lower=$(printf '%s' "$file" | tr '[:upper:]' '[:lower:]')
case "$lower" in *.png|*.jpg|*.jpeg|*.webp|*.tiff|*.tif) ;; *) exit 0 ;; esac
case "$file" in *"/raw/"*|*"/original/"*|*_original.*|*_full.*|*_raw.*) exit 0 ;; esac
dims=$(sips -g pixelWidth -g pixelHeight "$file" 2>/dev/null || true)
w=$(printf '%s' "$dims" | awk '/pixelWidth/ {print $2}')
h=$(printf '%s' "$dims" | awk '/pixelHeight/ {print $2}')
[[ -z "$w" || -z "$h" ]] && exit 0
(( (w > h ? w : h) <= 2000 )) && exit 0
sips -Z 1440 "$file" --out "$file" >/dev/null 2>&1 || exit 0
printf 'Hook: resized %s from %dx%d -> max 1440px.\n' "$file" "$w" "$h" >&2

Wire it into ~/.claude/settings.json:

"hooks": {
  "PreToolUse": [
    {
      "matcher": "Read",
      "hooks": [{ "type": "command", "command": "bash ~/.claude/hooks/resize-oversized-image.sh" }]
    }
  ]
}

chmod +x the script. Needs sips (macOS built-in) and jq. For Linux, swap sips -Z 1440 for magick mogrify -resize '1440x1440>' "$file".

Not a substitute for the real fix — Claude Code should cap image dimensions at ingestion, before they enter context — but it stops sessions getting bricked while you wait.

Update on my earlier comment about the PreToolUse hook workaround:

The hook does NOT catch Chrome/Playwright MCP screenshots. The hook I shared (resize images >2000px before Read) only fires when Claude calls the Read tool on a file path. MCP screenshot tools like mcp__claude-in-chrome__computer (action=screenshot) return the image as base64 inline in the tool result — it never touches the filesystem, so the hook can't see or modify it. I hit the 2000px error again mid-session after thinking it was solved. Worth knowing if anyone else tries this approach.

Workaround that actually works on a Retina Mac: force Chrome to run at 1x DPR so screenshots capture at CSS pixel size, not 2x. Fully quit Chrome, then relaunch with:

killall "Google Chrome"
sleep 1
open -a "Google Chrome" --args --force-device-scale-factor=1

Verify with devicePixelRatio in any tab's console — should return 1. A 1440×900 viewport then captures at 1440×900 instead of 2880×1800, well under the 2000px cap.

Trade-off: every page in Chrome now looks slightly blurry on Retina (Chrome is rasterising at half physical density). Reversible by quitting Chrome and relaunching without the flag. I'll probably use a second browser (Safari/Arc/Firefox) for normal browsing and keep Chrome in 1x mode for Claude Code audit sessions. Not ideal, but it's a reliable fix until Chrome MCP exposes a dpr or max_dimension parameter, or the core 2000px limit is lifted.

Other options I considered but haven't tried yet:

• Switch audit work to Playwright MCP (defaults to 1x CSS pixels) — loses the user's signed-in Chrome session though
• Resize the window smaller (e.g. 960×600 → 1920×1200 at 2x, just under the limit) — fiddly, easy to forget

Really the root cause is that image dimension limits get exceeded from tool outputs Claude has no control over. A max_image_dimension session setting that auto-downsamples inline image tool results on the Claude Code side would close this for everyone regardless of which MCP they use.

+1, Windows 11 / Claude Code latest. Hit this reading local PNG figures from disk (not MCP screenshots) — a LaTeX report session where I asked Claude to view a 2400px figure export via the Read tool. Single oversized image killed the request with the exact error text, even though only ~3–4 images were in context prior. Retry got the same error on the next tool call, session was effectively bricked.

Subtle detail the thread may not have covered: the session was still interactively responsive (I could type the next turn), but every subsequent request round-tripped the same 400. So it's not that the turn fails — the whole context is poisoned by the oversized image for all future turns.

Concrete ask matching the thread consensus: auto-downsample on ingest at the Read/tool-result boundary (longest edge → 2000px), before the image enters context. Hooks help on disk reads but don't help the MCP inline-base64 case that jezweb called out above.

I get this after like 2 images, have to start an entirely new session, quite annoying as i only get a few minutes into a session and send a screenshot and the entire session is borked after it hits the api error.

Adding a data point + workaround for anyone hitting this on macOS:

Trigger: macOS screenshots taken at native retina DPI are typically 3024×1890+ on 14"–16" MacBooks, which exceeds the 2000px many-image limit. After ~5–8 such pasted/dragged screenshots accumulate in one session, the API rejects every subsequent turn — even text-only ones — because the offending images get re-sent from history.

Workaround (until Claude Code does this client-side):

1. Move the macOS screenshot save location to a non-TCC-restricted folder:

``bash
mkdir -p ~/Screenshots
defaults write com.apple.screencapture location ~/Screenshots
killall SystemUIServer
``

1. Add a launchd LaunchAgent that polls ~/Screenshots every 10 seconds and runs sips -Z 1900 <file> on any PNG over the threshold. The user-context shell granted ~/Screenshots access via TCC at first write, so launchd inherits it.

Result: every screenshot is downscaled to ≤1900px on its long edge before you can drag it into Claude Code. The deadlock stops happening.

Watching ~/Desktop directly with launchd does not work — TCC blocks launchd-spawned processes from reading ~/Desktop even when the user's terminal has access. That's why the workaround moves screenshots to a fresh non-protected folder.

Doesn't fix the underlying bug, but unblocks the workflow.

This is a duplicate of #13480, which was fixed as of version 2.1.126.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.