[Bug] Anthropic API Error: Image dimensions exceed max allowed size (8000 pixels)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/11576
2. https://github.com/anthropics/claude-code/issues/10959
3. https://github.com/anthropics/claude-code/issues/9049

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Image Dimension Error - Conversation Killer

The API is rejecting your image because it's >8000 pixels in at least one dimension. Claude Code should've resized it before sending.

Immediate Fix

Clear the problematic message from history:

# Option 1: Skip the image turn
/clear  # Clears recent conversation

# Option 2: Start fresh session
Ctrl+D
claude

Root Cause

Claude Code took a screenshot or you attached an image that's too large:

• Max API limit: 8000x8000 pixels
• Your image: Probably a hi-DPI screenshot (e.g., 5120x2880 on 5K display)

The bug: Claude Code should automatically resize images BEFORE sending to API, but it's not.

Verify Image Size

Check the actual image dimensions:

# Find recent screenshots:
find ~/.claude/projects -name "*.png" -mtime -1 -exec file {} \;

# Or check logs:
grep -r "image.source.base64" ~/.claude/projects/*/[session-id].jsonl | head -1

If you see dimensions >8000, that's your culprit.

Workaround: Resize Before Sharing

If you need to share large screenshots:

# macOS:
sips -Z 4000 screenshot.png

# Linux:
convert screenshot.png -resize 4000x4000\> resized.png

# Windows:
magick screenshot.png -resize 4000x4000 resized.png

Then share the resized version.

Proper Fix (Needs Anthropic)

Claude Code should:

// Before sending image to API:
async function prepareImage(imagePath: string): Promise<Buffer> {
  const img = await loadImage(imagePath);
  const maxDim = 8000;
  
  if (img.width > maxDim || img.height > maxDim) {
    // Resize maintaining aspect ratio:
    const scale = maxDim / Math.max(img.width, img.height);
    return await img.resize(
      Math.floor(img.width * scale),
      Math.floor(img.height * scale)
    );
  }
  
  return img.buffer();
}

Feature Request

Add config for max image dimensions:

// ~/.claude/config.json
{
  "tools": {
    "computer": {
      "max_screenshot_dimension": 4000,  // Default to safe value
      "screenshot_quality": "medium"
    }
  }
}

Recovery

If your conversation is stuck:

# Find the broken session:
ls -lt ~/.claude/projects/*/sessions/ | head -5

# Remove last N messages:
# (This is advanced - backup first)
cp session.jsonl session.jsonl.bak
head -n -5 session.jsonl > session_fixed.jsonl
mv session_fixed.jsonl session.jsonl

Then restart Claude Code - it'll load the truncated history without the bad image.

I also ran into this and since I'm working with images on a project, had Claude add the following hook to check image dimensions as a PreToolUse hook. This doesn't fix the problem but it at least avoids corrupting the chat (which is highly disruptive to my workflow.)

---

.claude/settings.local.json - Hook configuration:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Read",
        "hooks": [{"type": "command", "command": ".claude/hooks/check-image-size.sh"}]
      }
    ]
  }
}

---

.claude/hooks/check-image-size.sh - Hook script that:

• Checks if file is an image (by extension)
• Uses identify (ImageMagick) or sips (macOS) to get dimensions
• Blocks with exit 2 if either dimension > 2000px
• Outputs message to stderr telling Claude to ask user to inspect manually

#!/bin/bash
#
# PreToolUse hook for Read tool
# Blocks reading images that exceed 2000px in either dimension
# (to avoid API errors with multi-image requests)
#

set -e

# Read JSON input from stdin
INPUT=$(cat)

# Extract file_path from tool_input
FILE_PATH=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty')

# If no file path, allow
if [[ -z "$FILE_PATH" ]]; then
  exit 0
fi

# Check if it's an image file by extension
if [[ ! "$FILE_PATH" =~ \.(png|jpg|jpeg|gif|bmp|webp|PNG|JPG|JPEG|GIF|BMP|WEBP)$ ]]; then
  exit 0
fi

# Check if file exists
if [[ ! -f "$FILE_PATH" ]]; then
  exit 0
fi

# Get image dimensions using identify (ImageMagick) or sips (macOS fallback)
if command -v identify &> /dev/null; then
  DIMENSIONS=$(identify -format "%w %h" "$FILE_PATH" 2>/dev/null | head -1)
  WIDTH=$(echo "$DIMENSIONS" | cut -d' ' -f1)
  HEIGHT=$(echo "$DIMENSIONS" | cut -d' ' -f2)
elif command -v sips &> /dev/null; then
  WIDTH=$(sips -g pixelWidth "$FILE_PATH" 2>/dev/null | grep pixelWidth | awk '{print $2}')
  HEIGHT=$(sips -g pixelHeight "$FILE_PATH" 2>/dev/null | grep pixelHeight | awk '{print $2}')
else
  # No tool to check dimensions, allow and hope for the best
  exit 0
fi

# Check if either dimension exceeds 2000px
MAX_DIM=2000

if [[ "$WIDTH" -gt "$MAX_DIM" ]] || [[ "$HEIGHT" -gt "$MAX_DIM" ]]; then
  echo "Image too large (${WIDTH}x${HEIGHT}px, max ${MAX_DIM}px). Tell the user to inspect this file manually: $FILE_PATH" >&2
  exit 2
fi

# Image is within limits, allow
exit 0

Hey @panozzaj! 👋

This is a really clever workaround! The PreToolUse hook approach is exactly the kind of defensive programming that saves workflows from breaking at the worst possible moment.

I love that you went conservative with the 2000px limit instead of cutting it close to 8000px - smart thinking about multi-image requests. The fallback chain (ImageMagick → sips → allow) also shows solid defensive design.

One small suggestion: You might want to add a note in the hook's header comment about why 2000px specifically (the multi-image scenario), since it's not immediately obvious and could save future debugging time.

Thanks for sharing this with the community - definitely going to help people working with images until Anthropic implements automatic resizing in the CLI! 🙌

---

*Side note for anyone implementing this: make sure to chmod +x .claude/hooks/check-image-size.sh after creating itecho ___BEGIN___COMMAND_OUTPUT_MARKER___ ; PS1= ; PS2= ; unset HISTFILE ; EC=0 ; echo ___BEGIN___COMMAND_DONE_MARKER___0 ; }

I had gotten this error:

API Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"messages.19.content.27.image.source.base64.data: At least one of the image dimensions exceed max allowed size for many-image requests: 2000 pixels"},"request_id":"req_abcdefg"}

Looks like maybe there's a many-images request that has different limits.

Hey everyone 👋

After repeatedly facing this issue, I decided to build claude-code-image-sanitizer using some of the
feedback and insights shared across related issues.

What it does:

• Automatically resizes oversized screenshots before they're sent to Claude's API
• Works with Playwright, Puppeteer, Chrome DevTools MCP, and other screenshot tools
• Includes a session repair tool to fix already-corrupted sessions

Would love any feedback/contributions!

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

omfg it's still opened
in 2026 claude code still can't work with images and not to crash the whole pipeline

Had not previously had this issue, but at some point on a bug hunting spree Claude started grabbing screen caps of 2160p images and this loop occurred for me as well however I was prompted to double press esc which allowed reversion to (much) earlier point, bugged point, or to clear. I think it's an important distinction if I'm not an outlier.

hitting this right now

https://github.com/anthropics/claude-code/issues/12351#issuecomment-3591811948. This worked.

Running /insights in Claude Code gave me this to put in my global ~/.claude/CLAUDE.md file:

When taking screenshots via Chrome DevTools MCP, always resize the viewport or use reduced-quality captures to stay under the 8000px image size limit. If an API error occurs due to image size, immediately switch to DOM inspection or text-based debugging rather than retrying screenshots.

This worked for me.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

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.