[BUG] Oversized image breaks conversation permanently - no way to recover without starting new chat

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/12351
2. https://github.com/anthropics/claude-code/issues/12867
3. https://github.com/anthropics/claude-code/issues/13341

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

I am having the same issue.

Also experiencing the same issue, after error chat cannot be continued: ⎿ API Error: 400
{"type":"error","error":{"type":"invalid_request_error","message":"messages.0.content.3.image.source.base64.data:
At least one of the image dimensions exceed max allowed size: 8000
pixels"

Yeah... very annoying, also happens for me:

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

Then it's just dead, you can't recover.

having the same issue

I would expect /compact to at least recover from this state, but even that doesn't work. It just shows you the same error, and I'm forced to start a new conversation.

/compact seems to work now

<img width="849" height="377" alt="Image" src="https://github.com/user-attachments/assets/444ce949-f3a2-4df3-ad35-7754c9f4bee3" /> compact also doesnt work for me. can anybody help

same issue and many times the problem was creeted by the claude chrome plugin itself - nothing i did. kills my chat.

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

and the chat is unrecoverable. (requires editing the jsonl file - removing the offending session events before it can be used again)

to be clear, the images used are NOT particularly large (actually fairly small many times)

What Should Happen?
It should NOT throw an API error, and it should NOT kill the chat (and require hand editing the jsonl to fix it)

Currently, I must start a fully new session with no previous context to proceed. However, my workflow depends on preserving conversational context across interactions.

Is there any temporary workaround that would allow context to be retained, or any recommended approach to handle this limitation?

Reproducing in the VS Code extension on Windows 11. After attaching an oversized image, every subsequent prompt returns the same error -- the conversation is effectively dead. /compact does not recover it.

Fixed it

Same issue I've having. Essentially there's no way to reverse it.

Same issue I've having. Essentially there's no way to reverse it.

Again , I have solved it , instead of pasting a link to solution , i am pasting the solution here

Fixed the problem : Claude Code Stuck on "Image base64 size exceeds API limit"

What Happened: basically we attached a large image in Claude Code. It got saved into the conversation JSONL file. Now every message fails with the same error because Claude Code re-sends all prior messages (including that image) as context on every API call. Even /compact and /context fail.

How to Fix :

Step 1 : Find your conversation file

Your stuck session ID is visible in the error or window title. The conversation file lives at:

C:\Users\<you>\.claude\projects\<project-hash>\<session-id>.jsonl

~/.claude/projects/<project-hash>/<session-id>.jsonl

Step 2: Back up the file ( I did , you dont have to really )

cp <session-id>.jsonl <session-id>.jsonl.backup

Step 3: Find which line has the oversized image

awk '{print NR, length($0)}' <session-id>.jsonl | sort -k2 -n -r | head -10
The largest line(s) are your culprits.

Step 4: Run this fix script ( convert it in your own lang ) :

import json
import sys
import shutil

if len(sys.argv) < 2:
    print("Usage: python fix.py <session-id>.jsonl")
    sys.exit(1)

input_file = sys.argv[1]
output_file = input_file + ".fixed"
backup_file = input_file + ".backup"
MAX_SIZE = 5 * 1024 * 1024  # 5MB

line_num = 0
fixed = 0

print(f"Processing: {input_file}")
shutil.copy2(input_file, backup_file)
print(f"Backup created: {backup_file}")

with open(input_file, "r", encoding="utf-8") as fin, \
     open(output_file, "w", encoding="utf-8") as fout:
    for line in fin:
        line_num += 1
        stripped = line.rstrip("\n")
        if not stripped:
            fout.write(line)
            continue
        try:
            obj = json.loads(stripped)
            content = obj.get("message", {}).get("content") if "message" in obj else None
            if isinstance(content, list):
                modified = False
                new_content = []
                for i, item in enumerate(content):
                    if (isinstance(item, dict)
                        and item.get("type") == "image"
                        and len(item.get("source", {}).get("data", "")) > MAX_SIZE):
                        size_mb = len(item["source"]["data"]) / (1024 * 1024)
                        print(f"  Line {line_num}: Replacing image[{i}] ({size_mb:.1f}MB)")
                        new_content.append({
                            "type": "text",
                            "text": f"[Image removed: {size_mb:.1f}MB exceeded 5MB limit]"
                        })
                        modified = True
                        fixed += 1
                    else:
                        new_content.append(item)
                if modified:
                    obj["message"]["content"] = new_content
                    fout.write(json.dumps(obj, ensure_ascii=False) + "\n")
                    continue
        except json.JSONDecodeError:
            pass
        fout.write(line)

print(f"\nDone. Processed {line_num} lines, fixed {fixed} image(s).")

if fixed > 0:
    shutil.move(output_file, input_file)
    print(f"Original replaced. Backup at: {backup_file}")
else:
    import os
    os.remove(output_file)
    print("No oversized images found. No changes made.")

Step 5: Replace the original

mv <session-id>.jsonl.fixed <session-id>.jsonl

Step 6: Reopen the session

Close and reopen Claude Code. The session should work again. Run /compact to clean up context.

What This Does
Finds any image in the conversation where the base64 string > 5MB
Replaces only that image with a small text placeholder
All your text, smaller images, tool calls, AI responses, and context stay intact
Nothing else is touched

<img width="850" height="452" alt="Image" src="https://github.com/user-attachments/assets/8130b789-531a-43cb-9cab-224ac43f3003" />

<img width="485" height="83" alt="Image" src="https://github.com/user-attachments/assets/c4b4aec8-6962-4e35-81ff-0056da82b298" /> This was in claude's chrome agent...

Workaround that worked for me:
I ran into the same issue: I got stuck with an image-size error, and opening a new session didn't help because the oversized image was still in the conversation history.
What fixed it: running /compact in the existing session. It summarised the entire conversation as text, which dropped the problematic image from the history entirely. After that, the session resumed normally with no errors.
Instead of starting a new session and losing context, try /compact first—it solved the issue without losing any of the analysis I had done.

I call this the PHYSICIAN, HEAL THYSELF!™ move to get the chat back without compaction:

• Copy the error you see, something like

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

• End the current session, you should see a To resume this session, use claude --resume <some_id> message

-----

Create a new session of Claude code.

hey dude. so an older chat of mine, <some_id>
doesn't open because of <copied_error>
find the chat in claude sessions, use ffmpeg to replace all images in the chat with compressed/low res versions
lmk when you're done
also give me a msg to tell it not to do this again I can copy paste there

Viola, you have your older chat back, just resume with claude --resume <some_id>!

Note: This root cause analysis was done collaboratively with Claude Code (Opus 4.6). If that bothers you, feel free to scroll past. Nobody's getting paid here — let alone using my own subscription to troubleshoot for Anthropic. Just sharing what I found in case it helps.

Root Cause (v2.1.76)

The image reading pipeline has no bail-out for non-image content. Three functions form the chain:

1. pF6 (magic byte detection) — defaults to "image/png" when bytes don't match any known format, instead of returning null:

// after checking PNG, JPEG, GIF, WebP magic bytes:
return "image/png";  // ← HTML, error text, anything unknown = "PNG"

2. XV8 (Read tool image handler) — when sharp correctly rejects the content ("unsupported image format"), the catch block wraps the raw bytes as PNG anyway:

try {
  O = await Bk(Y, z, w);    // sharp rejects
} catch(H) {
  O = bP1(Y, w, z);         // fallback: base64-encode raw bytes, label as PNG, send to API
}

3. rf4 (paste-time handler) — calls sharp with no catch block at all, crashing the input handler when a bad image propagates via copy-paste.

Minimal Patch

Tested on a stock v2.1.76 devcontainer (no MCP, no custom config). Apply to cli.js:

# python3 patch.py $(which claude | xargs readlink -f | xargs dirname)/cli.js
import sys
with open(sys.argv[1], 'r') as f: content = f.read()

# 1. pF6: return null for unknown magic bytes
content = content.replace(
    'return"image/webp"}return"image/png"}',
    'return"image/webp"}return null}', 1)

# 2. XV8: bail out when pF6 returns null
content = content.replace(
    'let _=pF6(Y),w=_.split("/")',
    'let _=pF6(Y);if(_===null)return{type:"text",file:{filePath:A,content:"[Not a valid image file]",numLines:0,startLine:1,totalLines:0}};let w=_.split("/")', 1)

# 3. rf4: skip non-images before sharp
content = content.replace(
    'let z=D8Y(K).slice(1).toLowerCase()||"png",_=await Bk(Y,Y.length,z)',
    'let z=D8Y(K).slice(1).toLowerCase()||"png";if(pF6(Y)===null)return null;let _=await Bk(Y,Y.length,z)', 1)

with open(sys.argv[1], 'w') as f:
    f.write(content)

Breaks on next npm update — meant as a stopgap, not a permanent solution.

Full write-up with both vectors (Read tool + paste propagation): https://github.com/tfvchow/field-notes-public/issues/55

I've hit this for the first time ever and it's happened 3x today.

summarised the entire conversation as text

This worked for me too with /compact

1M context window makes this significantly worse

With the recent upgrade to 1M context, this bug now has a much bigger impact window. My session hit this error at 423K tokens used — only 42% of the 1M context window.

The inconsistency is jarring:

1. Image gets pasted at >2000px → accepted without complaint, tokenized, used successfully
2. Session continues, more images accumulate via tool results and pasted screenshots
3. At ~400K tokens (well under 1M limit) → the same image that was accepted earlier now triggers: "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."
4. Every subsequent message fails — even single-character messages like "h"
5. Session is bricked with 577K tokens of unused capacity

The 2000px multi-image dimension limit appears to be a legacy constraint from the 200K context era, where "many images" and "approaching context limit" roughly coincided. Now with 1M context, users hit the dimension limit at less than half capacity — effectively halving the usable context window for any image-heavy workflow.

The core UX problem: If the API accepts an image at the start of a session, it should continue to work with that same image until actual token limits are reached. Retroactively rejecting it mid-session — while the context window is barely half full — is broken behaviour.

Expected: Either (a) reject/resize oversized images at paste time, or (b) scale the multi-image dimension limit proportionally with the context window size.

Screenshot — session bricked at 423K/1M tokens, every message returns the same error:

!Image

Environment: Claude Code 2.1.77, Windows 11, Opus 4.6 (1M context), Anthropic API (Max subscription)

Exactly the same bug "An image in the conversation exceeds the dimension limit for many-image requests (2000px). Start a new session with fewer images." Even "/compact" didn't help, there's no way but to just create a new session.

Is there a workaround?

I call this the PHYSICIAN, HEAL THYSELF!™ move to get the chat back without compaction: Copy the error you see, something like API Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"messages.21.content.91.image.source.base64.data: At least one of the image dimensions exceed max allowed size for many-image requests: 2000 pixels"}} End the current session, you should see a To resume this session, use claude --resume <some_id> message Create a new session of Claude code. `` hey dude. so an older chat of mine, <some_id> doesn't open because of <copied_error> find the chat in claude sessions, use ffmpeg to replace all images in the chat with compressed/low res versions lmk when you're done also give me a msg to tell it not to do this again I can copy paste there ` Viola, you have your older chat back, just resume with claude --resume <some_id>`!

This one worked for me. I used imagemagick's convert though

I call this the PHYSICIAN, HEAL THYSELF!™ move to get the chat back without compaction: […] Viola, you have your older chat back, just resume with claude --resume <some_id>!

Well, @benmaier I owe you a beer ‘cause this approach worked for me!

@joelisfar nope, we both owe @CatalanCabbage a beer each :)

https://github.com/anthropics/claude-code/issues/13480#issuecomment-4058025107

this is still an issue if you are using Claude Desktop. As you won't know the session ID either, and no way to resume

> I call this the PHYSICIAN, HEAL THYSELF!™ move to get the chat back without compaction: > `` > * Copy the error you see, something like > ` > > > > > > > > > > > > API Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"messages.21.content.91.image.source.base64.data: At least one of the image dimensions exceed max allowed size for many-image requests: 2000 pixels"}} > ` > * End the current session, you should see a To resume this session, use claude --resume <some_id> message > ` > > > > > > > > > > > > Create a new session of Claude code. > ` > hey dude. so an older chat of mine, <some_id> > doesn't open because of <copied_error> > find the chat in claude sessions, use ffmpeg to replace all images in the chat with compressed/low res versions > lmk when you're done > also give me a msg to tell it not to do this again I can copy paste there > ` > > > > > Viola, you have your older chat back, just resume with claude --resume <some_id>! This one worked for me. I used imagemagick's convert` though

This worked on Claude code desktop - Just tell it the name of the chat instead of the the id.
@benmaier you are a lifesaver. The morning after you have @joelisfar's beer, coffee on me!

I'm having the exact same issue at 120k context (1m window), first time seeing it.

<img width="2366" height="216" alt="Image" src="https://github.com/user-attachments/assets/4dacd99d-5900-43ae-99c3-3b3911b6e840" />

The workaround above works. Thanks.

I call this the PHYSICIAN, HEAL THYSELF!™ move to get the chat back without compaction: Copy the error you see, something like API Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"messages.21.content.91.image.source.base64.data: At least one of the image dimensions exceed max allowed size for many-image requests: 2000 pixels"}} End the current session, you should see a To resume this session, use claude --resume <some_id> message Create a new session of Claude code. `` hey dude. so an older chat of mine, <some_id> doesn't open because of <copied_error> find the chat in claude sessions, use ffmpeg to replace all images in the chat with compressed/low res versions lmk when you're done also give me a msg to tell it not to do this again I can copy paste there ` Viola, you have your older chat back, just resume with claude --resume <some_id>`!

this worked for me, thanks!

At this point I just write, in a new chat:

Please find the conversation/session named the_conversation_name and downsize all of its images to "heal" it

And it works!

Still hitting this as of April 2, 2026.

What happened: Pasted a full-page screenshot (2984x8340) into the VS Code extension chat panel. Got the expected 400 error about image dimensions exceeding 8000px. But every subsequent message -- even plain text with no image -- hit the same 400 error because the oversized image stayed in conversation history at messages.14.content.1.

The session was completely bricked. The only recovery was using the rewind button to fork the conversation from before the image was sent, which loses all context after that point.

Environment:

• Claude Code CLI: 2.1.89
• Claude Code VS Code Extension: 2.1.90
• Platform: Claude Max (not API)
• OS: macOS 26.3.1 (Apple M2 Pro)
• Model: Opus

Error (repeats on every turn after the initial failure):

API Error: 400 {"type":"error","error":{"type":"invalid_request_error",
"message":"messages.14.content.1.image.source.base64.data: At least one of 
the image dimensions exceed max allowed size: 8000 pixels"}}

The message index (messages.14) stays the same across turns, confirming it is re-validating the old message, not the new one.

Suggested fix priority:

1. Downscale images before sending (prevents the error entirely)
2. Strip/replace rejected images from history after a 400 (allows recovery)
3. At minimum, surface a clear error telling the user the session is stuck and suggest using the rewind/fork feature to recover

using /compact helped me to continue the conversation in the same session.

I should note that on claude CHROME extension, none of these solutions work. This basically makes the claude chrome extension almost completely unusable.

@mythos please come in and fix this

This helped me fix the issue https://github.com/anthropics/claude-code/issues/13480#issuecomment-4058025107 Thanks, @CatalanCabbage !

Hit this today mid-session while pushing PRs. Pasted a Proxmox dashboard screenshot, continued working, then every subsequent message (even plain text) returned the same error. Session was completely unrecoverable.

The core issue isn't the image rejection itself. It's that the oversized image stays in conversation history and blocks every future API call, including /compact. The only option is starting a new session and losing your context.

For what it's worth, I paste screenshots regularly throughout sessions (infrastructure dashboards, UI testing, browser state). One image per session isn't really a realistic constraint for hands-on development work. It would be great if the API could auto-downscale images on ingest, or at least strip the offending image from history so the session can continue.

Adding another signal here because this is actively coming up in real workflows. Appreciate the work on this.

@becerratops

The only option is starting a new session and losing your context

Workaround to continue the chat: https://github.com/anthropics/claude-code/issues/13480#issuecomment-4058025107

🔄 Alternative Recovery Method: Session Replay via JSONL

Here's another approach that works great — especially when you want to fully restore context from a broken or lost session without needing ffmpeg or manual session ID wrangling.

---

Step 1: Navigate to your Claude sessions folder

Go to:

C:\Users\<YourUsername>\.claude\projects\

On macOS/Linux: ~/.claude/projects/

Click into the folder.

Step 2: Find your project folder

Select the folder that corresponds to the project you were working in. The folder names map to your project directories.

Step 3: Locate the most recent .jsonl file

Look for the .jsonl file with the most recent modified date/time — this is your last session's conversation log. It contains the full history of messages, tool calls, and context from that session.

Step 4: Start a fresh Claude Code session

Open a new Claude Code or Claude Desktop session in the same project directory where your project lives.

Step 5: Run /init for context

Run:

/init

This re-initializes the project context (reads CLAUDE.md, project structure, etc.) so the new session understands the codebase.

Step 6: Drag the .jsonl file into the chat

Drag the .jsonl file directly into the chat input, then instruct Claude to analyze it and get caught up:

"Analyze this session log and get fully caught up on where we left off. Resume the work from this context."

• Long sessions → Claude will automatically launch multiple agents to parallelize the analysis
• Short sessions → A single agent will pull in the context directly

Step 7: 🎉 Celebrate

You're back in action with full context restored — no broken conversation state, no lingering image errors.

---

<details>
<summary><strong>💡 Why this works</strong></summary>

The .jsonl files in ~/.claude/projects/ contain the complete conversation history including all messages, tool calls, file reads, and edits. By feeding this into a fresh session, Claude can reconstruct the full working context without inheriting the corrupted conversation state (like the stuck oversized image that causes the 400 error loop).

This is essentially a clean-room context transfer — you get all the knowledge without the broken state.

</details>

---

TL;DR: Fresh session + /init + drag old .jsonl = full context recovery without the broken image in the conversation history.

Tagging everyone who's been affected by this — the workaround above might help you recover your sessions:

@precisionpete @Abdelrhman-Rayis @CatalanCabbage @DavideDaniel @DawidBester @HikariKogen @Krawch007 @Qiaogun @RhysBlackbeard @Saturate @a5x10 @benmaier @bigshiny90 @cjserio @d0nk3yhm @ekokodan @electric-sheepai @joelisfar @jonnychn @mahesha-quattr @nomad23 @paocg01-ops @peterHoburg @rkarimpour-diligent @stevenirby @tfvchow @thiebes @zlDev

Thanks @QuicksilverSlick , I prefer the trick with imagemagick's convert, burns less tokens and keeps the conversation exactly as is otherwise

Thanks @QuicksilverSlick , I prefer the trick with imagemagick's convert, burns less tokens and keeps the conversation exactly as is otherwise

what is the trick , can you please share @benmaier

I hit this same issue and built a tool to automate the fix.

session-rescue.py is a zero-dependency Python script that finds broken Claude Code sessions and strips the base64-encoded images that trigger the "many-image dimension limit" error after sleep/wake cycles.

It works by:

1. Finding sessions by ID or name
2. Scanning JSONL files for base64 image blocks
3. Replacing images with placeholder text
4. Creating numbered backups before modification

Install: Just ask Claude Code to install the skill from the GitHub repo:

skill install https://github.com/ianbmacdonald/claude-session-rescue

No pip, no venv, no dependencies — pure stdlib.

Repo: https://github.com/ianbmacdonald/claude-session-rescue

Hope this helps others who are stuck waiting for an official fix.

Adding regression data that may help track down the issue:

• v2.1.92: Works fine — long sessions with many screenshots (6+) complete without errors
• v2.1.112: Breaks after accumulating ~3-6 images, enters unrecoverable error loop

Environment: Cursor, Pop!_OS 24.04 LTS, 2560x1600 display, Max plan.

Downgrading to v2.1.92 is a reliable workaround. This suggests the regression was introduced between these two versions.

Closing our duplicate issue #50264 in favor of this one.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Another datapoint on the regression question:

Same UI-review workflow across model versions — Opus 4.6 never hit this, Opus 4.7 hits it reliably. On Claude Code v2.1.111 via the claude-in-chrome MCP (Retina 2x captures from a 1440px viewport land at ~2880px wide).

This lines up with @lucianalima777's v2.1.92→v2.1.112 regression window but also suggests API-side validation tightened with the 4.7 rollout — oversized Retina screenshots that historically passed now fail. Once one lands in context, the whole session is poisoned per the other reports above.

Capture surfaces I've confirmed affected: claude-in-chrome MCP screenshots, preview-server MCP screenshots. Any tool that submits native-DPI images without client-side downscaling.

Same error. Can't believe it's been there since December.

I started getting this error after "upgrading" to Opus 4.7

Same error

Same bug in Claude Cowork. What's the point of advertising the "File sorting" feature if it fails on a simple screenshot and breaks the whole chat?

Making this very much not usable. I hit this about every 10 minutes. max plan.

same error

> I call this the PHYSICIAN, HEAL THYSELF!™ move to get the chat back without compaction: > > Copy the error you see, something like > > > API Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"messages.21.content.91.image.source.base64.data: At least one of the image dimensions exceed max allowed size for many-image requests: 2000 pixels"}} > > End the current session, you should see a To resume this session, use claude --resume <some_id> message > > > Create a new session of Claude code. > > `` > hey dude. so an older chat of mine, <some_id> > doesn't open because of <copied_error> > find the chat in claude sessions, use ffmpeg to replace all images in the chat with compressed/low res versions > lmk when you're done > also give me a msg to tell it not to do this again I can copy paste there > ` > > Viola, you have your older chat back, just resume with claude --resume <some_id>! This one worked for me. I used imagemagick's convert` though

quote-replying with the solution that works for me here again for visibility

went back to version 2.1.79 that uses Opus 4.6 and there is no more error.

@claude how have you not adressed this since December? Almost 25% of my sessions hit this error, and the session is bricked. At least put a px upload gate to avoid this from happening. Come on Claude.

Anthropic, if you cannot make the business, probably you should control numbers of subscribers

@claude this issue is haunting many and will cause major break. Have a basic error handeling for god's sake. you can always skip the 2000Px read or raise flag asynchronously.

Current workaround includes running '/compact' and then carrying the conversation

same here ((

It's ridiculous that's still an issue, please fix this. Literally everyone of my sessions (as someone who uses Claude Code to build UIs and uses a lot of screenshots) run into this.

Just hit the same bug.

+1 this happens in mac a lot. may be the resolution is too highi

Just encountered this same issue by processing slide decks in pdf.

please provide a way to clean the images from conv only.

+1 version 2.1.119 (Claude Code) on Ubuntu Noble

+1 - Claude Code CLI 2.1.119 on Windows 11, Powershell 7 terminal inside VS Code

+1 - what's worse: i tried to rewind to delete message with many pics, the terminal stuck and NOT responding to any inputs anymore (ESC, Ctrl-C, enter).

Adding another data point — hit this today on Claude Code 1.1.x (macOS). Long working session with ~25 screenshots accumulated in context. Once the limit triggered, every subsequent request failed with the same "exceeds the dimension limit for many-image requests (2000px)" error.

Two pain points the existing discussion hasn't emphasized:

1. The error message is actively misleading. It tells users to run /compact, but /compact summarizes the entire conversation and irreversibly loses tool outputs, file contents, and discussion detail. For multi-hour sessions that's a huge cost to pay for what is really just an image-size problem. The suggested remedy doesn't match the actual fault.

1. No "drop images only, keep text" escape hatch exists. Users are forced to choose between losing the conversation (/compact) or abandoning the session entirely. Deleting files from ~/.claude/image-cache/ doesn't help because the images are already baked into the transcript/JSONL that gets sent on every request.

1. Retina screenshot trap on macOS. Cmd+Shift+3/4 produces images at 2x logical size. A screenshot that looks "normal" in the terminal preview is actually 2500–2900px wide. Users have no visual cue that they're about to poison the session.

Strong +1 on the suggested fixes upstream — client-side downscaling before the image enters the transcript would solve this transparently and is the right layer to fix it at. A /drop-images or similar surgical command would also be a meaningful improvement for sessions that have already hit the wall.

One nuance on the downscaling suggestion: naive resize to 2000px should be safe because the vision encoder already resizes to ~1568px internally, so a client-side resize to 2000px should not introduce meaningful quality loss for typical screenshots. The cases where it does hurt (dense small text, full-screen 4K captures with multiple panels) already fail at the encoder stage regardless — the original resolution was never going to reach the model intact. For those edge cases, tiling tall screenshots into multiple sub-2000px images, or surfacing a warning at capture/paste time so the user can re-crop, would be more useful than trying to preserve the original resolution end-to-end.

Bricks my sessions almost daily, specifically when I'm working on UI intensive tasks and it takes screenshots to verify. @fdjkgh580 has the right idea, just drop his post into the CLI as is. Crazy that this issue is ongoing for so long.

Yes, this is definitely an issue that I would like to see solved for good, but in the meanwhile my Claude and I have devised this workaround: every time Claude needs to load an image into the context (in my case, mostly Maestro test screenshots from a 1080×2400 phone screen), it first shells out to ImageMagick to shrink it under the 2000-px ceiling — e.g. convert big.png -resize '1800x1800>' /tmp/small.png— and reads the resized copy instead of the original. The > flag is the key bit: it only shrinks images that exceed the box, never enlarges, so it's safe to apply unconditionally.

To make this stick across sessions I saved it as a feedback memory, which Claude consults at the start of every session:

---
name: Resize images > 2000px before Read
description: I cannot reliably Read images whose width OR height exceeds 2000 pixels; shrink them first
type: feedback
---
Rule: any image with width OR height > 2000 px must be resized before Read.
How: `convert in.png -resize '1800x1800>' /tmp/in_small.png` then Read the copy. The `>` flag only shrinks, never enlarges, and preserves aspect ratio.

End result: an oversized image never reaches the API in the first place, so the conversation can't get poisoned. Not a fix — if Claude forgets, or if I paste an image directly into the prompt, things still break — but it's been keeping my long debugging sessions alive.

@bcherny please fix

Bricks my session pretty much every 10 minutes: ´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.´

WTF how is this still not fixed? I've been having this issue for months and totally just messes up your entire flow. This bug is now 6 months old... Can someone at Anthropic fix this please??

I am having this issue in almost every second chat and it's impossible to avoid. I can't continue in the chat despite my token consumption is less than 50K.

@shootdaj I have used https://github.com/asifkibria/claude-code-toolkit and has fixed it for me multiple time

Same here, breaks the flow and a conversation completly. It doesnt matter if I try to rewind to a point of the conversation before the "supposed image" was added, and still it never "recovers".

🔧 FIX

> At least one of the image dimensions exceed max allowed size for many-image requests: 2000 pixels

Workaround that resizes embedded images in your conversation jsonl in-place: https://github.com/benmaier/fix-claude-convo-images
Uses imagemagick (must be installed separately); Only tested on macOS; Use at your own risk.

Have Claude install it for you (paste into a Claude Code session other than the broken one):

``
Read https://github.com/benmaier/fix-claude-convo-images, audit resize_conversation_images.py for safety (no network calls, only touches ~/.claude/projects/, backs up before rewriting), report
findings, then install with the curl one-liner from the README and verify with fix-claude-convo-images --list.
``

also getting this, very annoying and feels broken

@shootdaj I have used https://github.com/asifkibria/claude-code-toolkit and has fixed it for me multiple time

It's amazing. I love the dashboard, it's just bit slow!

# 🔧 FIX > At least one of the image dimensions exceed max allowed size for many-image requests: 2000 pixels Workaround that resizes embedded images in your conversation jsonl in-place: https://github.com/benmaier/fix-claude-convo-images Uses imagemagick (must be installed separately); Only tested on macOS; Use at your own risk. Have Claude install it for you (paste into a Claude Code session _other than_ the broken one): `` Read https://github.com/benmaier/fix-claude-convo-images, audit resize_conversation_images.py for safety (no network calls, only touches ~/.claude/projects/, backs up before rewriting), report findings, then install with the curl one-liner from the README and verify with fix-claude-convo-images --list. ``

This worked, thanks!

This bug sucks. Thank god I learned about /compact. But Jesus, fix this already.

This issue was fixed as of version 2.1.126.

This issue was fixed as of version 2.1.126.

Still have the issue in Claude Code Desktop (Windows) with the latest version (Claude 1.5354.0 (9a9e3d) 2026-04-29T01:14:34.000Z).

<img width="836" height="136" alt="Image" src="https://github.com/user-attachments/assets/e7adbcaf-7a74-4ec6-84d8-8d3d49d67d27" />

me too :(

<img width="1230" height="162" alt="Image" src="https://github.com/user-attachments/assets/ece48aa2-49af-4662-ba54-3a64a0624c8d" />

It's not fixed at all

<img width="476" height="43" alt="Image" src="https://github.com/user-attachments/assets/59297b4e-e8d2-4d57-bf53-7bcb67bad59c" />
Stupid claude as always, claims something works, while it clearly is not.

Same error in Claude's Chrome add-on.

This issue was fixed as of version 2.1.126.

Just happened to me again. I was running 2.1.111 before then I exited and re-ran claude, and it's .126 now, but the error still happens. Could it be you fixed the error occuring but no auto-healing?

/compact fixed it for me.

I have just hit this issue. I am not uploading any images from the conversation window. I have a mockup / prototype running under the control of Claude. It looks like however Claude is managing / updating this is causing this issue. This is very painful. I see this type of issue has been around for a while now. Please can it be resolved as I am going to have to start a new session and some of the context of what we have been doing will be lost.

This issue has not been fixed. I'm not sure why they closed it.

The fix I have been using is to open another session in Claude Code. Then ask it to find the corrupted session file and remove the offending attachment. Then reopen the original session. That seems to have worked a few times.

A better fix would be for CC to notice that the image is too big and reject it.

Just note that the issue happened in my case as Claude was taking screenshots of web app as we were iterating through design and took once that hit this bug. Please resolve.

same issue yes, it started taking screenshots and breaks every session permanantely.

Still a issue for me as well.

Still an issue - and confirmed that using a new code session to fix the previous one does work as a workaround.

+1

Use /compact to resolve the error temporarily in the same chat session. I am not facing the error since I upgraded the application.
App upgrade is another labyrinth jn the process.

I fired up a new session in Claude Code (desktop app) and asked it to figure out how to fix the original session. And it did. Session recovered!

(There was a round or two of it figuring things out that I didn't screenshot)

<img width="775" height="136" alt="Image" src="https://github.com/user-attachments/assets/e0b8e1cd-364e-4b66-bcfd-59800b93bad0" />

<img width="991" height="545" alt="Image" src="https://github.com/user-attachments/assets/7fe902c5-0cf9-49d7-9b4f-02df65409dc5" />

<img width="986" height="304" alt="Image" src="https://github.com/user-attachments/assets/ac6319a7-0dfa-4bb6-9b92-49fd6cd36c4b" />

still getting this "An image in the conversation exceeds the dimension limit for many-image requests (2000px). Start a new session with fewer images." in latest version, claude code desktop macos. esc esc used to let me roll back but it doesn't always work, get "Can't rewind to this message" sometimes. please fix @bcherny

windows 11, проблема сейчас актуальна

I’ve had to fix that same session 2 more times (and it worked both times). I had Claude write instructions that you should be able to paste into another conversation in Claude Code.

I'm hitting "An image in the conversation exceeds the dimension limit for many-image requests (2000px)" from a pasted Retina screenshot. Fix it:
1. Find the holding process: each running session writes `~/.claude/sessions/<pid>.json` with `{pid, sessionId, cwd}`. List them and ask me which `cwd` is the poisoned session. Capture pid and sessionId.
2. The log is `~/.claude/projects/<encoded-cwd>/<sessionId>.jsonl` (cwd encoded by replacing `/` with `-`). Back it up with `cp -p` to a `.bak.<timestamp>` sibling.
3. With Python + Pillow (`python3 -m pip install --user Pillow` if missing), walk every line. For each `{"type":"image","source":{"type":"base64","media_type":"image/...","data":"..."}}` block (anywhere in the tree), decode; if `max(w,h) > 2000`, downscale to fit ≤2000px on the longest edge (LANCZOS), re-encode as JPEG q85, base64 back. Re-serialize modified lines with compact `json.dumps`. Atomic-replace via temp file + `shutil.move`. `chmod 600`.
4. Verify: every line still parses as JSON; no image > 2000px remains. Report the count fixed.
5. `kill <pid>` to drop the in-memory copy.
6. Tell me to reopen that session in the Claude desktop app. CCD respawns and reads the fixed JSONL — the next send should succeed.
Keep the backup until I confirm it works.

It also suggested 3 potential more permanent hacks to avoid hitting the issue again. I haven't tried them yet, but probably will soon if this keeps happening.

This is going to keep happening every time you paste a Retina screenshot taller than 2000px (≈ half a vertically-cropped iPhone screen). A few permanent options if you want to stop chasing this: 1. Auto-fix daemon — I can write a small launchd-watched script that monitors ~/.claude/projects/-Users-davidbarnard-Documents-Grit-Factory/*.jsonl and downscales any oversized image as it appears, then signals the holding process. Roughly 30 lines of Python plus a .plist. Self-healing, no manual chase. 2. macOS-side fix — Take screenshots into a folder where Hammerspoon (or a fswatch script) automatically resizes them to ≤1800px on the longest edge before you paste them. Nothing for me to maintain in CCD. 3. Resize on paste — drag your Retina screenshot through Preview's Tools → Adjust Size... (or use sips -Z 1800 ... from a Quick Action) before pasting.

Still an issue, broke my 1h+ autonomous workload when it took screenshots and pasted them in the chat. I didn't even paste anything.

While we wait for Anthropic to fix the issue for good, I would like to repost my solution which reliably works around the issue in every session in which Claude tries to load screenshots, no need to "clean up" poisoned sessions after the fact:

https://github.com/anthropics/claude-code/issues/13480#issuecomment-4325900046

Yes, this is definitely an issue that I would like to see solved for good, but in the meanwhile my Claude and I have devised this workaround: every time Claude needs to load an image into the context (in my case, mostly Maestro test screenshots from a 1080×2400 phone screen), it first shells out to ImageMagick to shrink it under the 2000-px ceiling — e.g. convert big.png -resize '1800x1800>' /tmp/small.png— and reads the resized copy instead of the original. The > flag is the key bit: it only shrinks images that exceed the box, never enlarges, so it's safe to apply unconditionally. To make this stick across sessions I saved it as a feedback memory, which Claude consults at the start of every session: `` --- name: Resize images > 2000px before Read description: I cannot reliably Read images whose width OR height exceeds 2000 pixels; shrink them first type: feedback --- Rule: any image with width OR height > 2000 px must be resized before Read. How: convert in.png -resize '1800x1800>' /tmp/in_small.png then Read the copy. The > flag only shrinks, never enlarges, and preserves aspect ratio. `` End result: an oversized image never reaches the API in the first place, so the conversation can't get poisoned. Not a fix — if Claude forgets, or if I paste an image directly into the prompt, things still break — but it's been keeping my long debugging sessions alive.

@LucaBoschetto I tried something similar, but Claude doesn't always remember.

Clean-up solution here in case it fails still: https://github.com/benmaier/fix-claude-convo-images

is this fixed

fix this stupid error asap

<img width="964" height="151" alt="Image" src="https://github.com/user-attachments/assets/4b135da3-28fc-4735-878d-258e5062c8ea" />

Workaround for the "I'm about to paste a screenshot" path (won't help when Claude itself takes the screenshot — that's a different code path, as @alexlyzhov noted above).

The Retina catch is sneaky: on macOS a 1700pt-looking screenshot is 3400px on disk, well over the API's 2000px cap. And it's not just width — the API rejects when either dimension exceeds the cap, so tall portrait screenshots break sessions too. Most screenshot tools (built-in macOS, Zight, etc.) don't expose a "cap to N pixels" setting, so files that look small slip through. HiDPI Linux/Windows users hit this too.

I built a tiny static page to take the friction out of resizing before paste, and I'm now using it myself before every screenshot paste into Claude Code:

https://github.com/yawalkar/image-resizer-for-claude-code

• Drop / paste (⌘V or Ctrl+V) / click → resized so the longest side fits → on your clipboard, ready to paste into Claude Code
• 100% client-side (Canvas + Clipboard API), no upload or storage
• Configurable thresholds via URL params (?trigger=2000&target=1800)
• One-click Deploy to Cloudflare Workers

Doesn't solve the underlying poisoned-session bug — the recovery scripts already in this thread are the right tool for that. This just keeps the human-paste path from triggering it in the first place. Happy to take issues or PRs if anyone hits an edge case.

How is this still not fixed?

I just ran into this issue. It looks like it's still not fixed.

I just found out _undersized_ images also break it. Claude generated a 4x4 PNG test image that broke itself. Ridiculous.

Getting this too and compacting (and maybe waiting) seem to be the only fixes for me but after compacting sometimes Claude has memory issues and doesn't know where it left off. It's a little strange that compacting is the solution for me because I wouldn't even normally need to do it at that time.

It got worse. The cleaning tool above no longer fixes it. The images get resized, but the session is still poisoned. Please fix @bcherny

How is this closed? literally happens every time I am asking to work with diagrams or images