[BUG] "Request too large (max 20MB)" error on small files (99KB PNG)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/8092
2. https://github.com/anthropics/claude-code/issues/26018
3. https://github.com/anthropics/claude-code/issues/30542

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

The error is misleading — it's not the individual file that's too large. It's the total API request payload (conversation history + compacted summaries + all tool outputs) that's approaching the 20MB limit. After multiple compaction cycles in a multi-day session, residual context accumulates.

What helps:

1. /clear instead of restarting. Resets conversation history while keeping CLAUDE.md loaded. Faster than a full restart and immediately resolves the size issue.

1. Avoid drag-and-drop images in long sessions. Each image gets base64-encoded into conversation history, which inflates context size much faster than text. Use Read tool with file paths instead — the output gets compacted more efficiently.

1. Monitor context with /cost. When you see usage climbing high, proactively /clear before you hit the wall. Beats the "it was working and suddenly stopped" experience.

1. For multi-day work, start fresh sessions per logical task. Each compaction cycle leaves some residual overhead. After several compactions, the accumulated overhead can push you near the limit even without large files.

The error message itself should probably say "Context too large, try /clear" rather than "Request too large (max 20MB)" — that would save a lot of confusion.

Thanks for the quick and thorough breakdown! The distinction between
individual file size vs total API payload context was exactly the "aha"
moment —
the error message really had me thinking it was the file itself.

Already implemented your suggestions:

• Added context management rules to my CLAUDE.md (avoid drag-drop images,

use file paths + Read tool, proactive /clear, handoff docs before clearing)

• Starting fresh sessions per logical task instead of multi-day marathons

The error message suggestion is spot on — "Context too large, try /clear"
would save a lot of confusion. Hope the team picks that up.

Really appreciate the fast response!

On Sun, Mar 15, 2026 at 6:02 PM ゆる草 @.***> wrote:

yurukusa left a comment (anthropics/claude-code#34751) <https://github.com/anthropics/claude-code/issues/34751#issuecomment-4064227793> The error is misleading — it's not the individual file that's too large. It's the total API request payload (conversation history + compacted summaries + all tool outputs) that's approaching the 20MB limit. After multiple compaction cycles in a multi-day session, residual context accumulates. What helps: 1. /clear instead of restarting. Resets conversation history while keeping CLAUDE.md loaded. Faster than a full restart and immediately resolves the size issue. 2. Avoid drag-and-drop images in long sessions. Each image gets base64-encoded into conversation history, which inflates context size much faster than text. Use Read tool with file paths instead — the output gets compacted more efficiently. 3. Monitor context with /cost. When you see usage climbing high, proactively /clear before you hit the wall. Beats the "it was working and suddenly stopped" experience. 4. For multi-day work, start fresh sessions per logical task. Each compaction cycle leaves some residual overhead. After several compactions, the accumulated overhead can push you near the limit even without large files. The error message itself should probably say "Context too large, try /clear" rather than "Request too large (max 20MB)" — that would save a lot of confusion. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/34751#issuecomment-4064227793>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZGCR4LZL3TSV6RW4CK4NUL4Q5AB3AVCNFSM6AAAAACWSVS2FSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DANRUGIZDONZZGM> . You are receiving this because you authored the thread.Message ID: @.***>

I have the same problem with MCP Chrome-Devtool. After only 1 screenshot !!
/clear do nothing. If I restart claude, the same

⏺ chrome-devtool - navigate_page (MCP)(type: "url", url: "http://localhost:3000")
⎿  Successfully navigated to http://localhost:3000.
## Pages
1: http://localhost:3000 [selected]

⏺ chrome-devtool - take_screenshot (MCP)
⎿  Took a screenshot of the current page's viewport.
⎿  [Image]

⏺ Request too large (max 20MB). Double press esc to go back and try with a smaller file.

have the same issue

Same herer

Same here

The best thing can do is optimize, and clear/compact. I have 5 monitors that drawns the request limit, after forcing clause not to make the request directly causing him to lock up...smh we finaly got this optimization. I have not have the error since, I suspect the cause will be different depending on your workflow.

Problem: The windows-mcp MCP server encodes screenshots as uncompressed PNG at 1920x1080
resolution, which on a complex multi-monitor desktop produces images of 8-10MB+. When
base64-encoded for MCP transport, this exceeds Claude Code's 20MB API request size limit (a known
bug tracked in GitHub issues #34751, #26018, #26019, #36469), causing Claude Code to either error
with "Request too large (max 20MB)" or hang indefinitely with no recovery path. Fix: Three changes
applied to windows_mcp/tools/_snapshot_helpers.py in the uv cache — (1) reduced MAX_IMAGE_WIDTH,
MAX_IMAGE_HEIGHT from 1920x1080 to 1280x720, (2) changed the image encoding from format="PNG" to
format="JPEG", quality=70, optimize=True with an RGBA→RGB conversion since JPEG doesn't support
alpha channels, (3) updated the MCP response format tag from format='png' to format='jpeg', and
additionally set MAX_MCP_OUTPUT_TOKENS=50000 in ~/.claude/settings.json to raise Claude Code's
default 25,000-token MCP response limit.

this is an INFURIATING ERROR. it totally tanks a conversation. The 'press esc to go back' is a terrible solution because we lose a ton of context or work.

I'm getting this as well. There really should be a /clear-files or /delete-images option that clears "all files" or "image files".

The error message right now might as well be updated to "This is the end of the road. Start a new session, and I hope you asked me to create memories..."

I have the same problem, I was struggling with the same issue in the GitHub Copilot chat where it was giving me the "invalid string length" message, and now I have the same problem here with Claude, it's terrible... Why can't you clear the images pool so you don't start a new session and lose context?

Run command :

/compact

This summarizes the conversation history into a compressed version so you can keep going without losing your project context. It's built exactly for this situation.

If /compact doesn't fully fix it:
Run this to clear just the images from the context while keeping the code/text history:

/clear images

To avoid this happening again:

Don't paste screenshots into Claude Code — describe the error in text instead
When the session gets long, run /compact proactively before hitting the limit

/compact still gives me the Rate Limit reached error.

I am facing the similar issue.

Same issue here!

What is the solution? It's bit frustrating.

same issue for me

It is very frustrating. On my side I use /compact and then I can drop images again. Far from ideal - It used to work just fine.

Guys, I ran into the same problem as well, but I was able to “reverse” it to some extent. I cleared the context (/clear), but in the new session, I asked Claude whether it would be possible to recover the context from the previous conversation. After an initial refusal, I asked it to analyze the installation directories, specifically to look for conversations in the history.jsonl file located at the root of the installation (~/.claude).

In that file, which contains one JSON object per line, there is enough information for it to “recover” the history:

display — the text you typed
sessionId — identifies the conversation (each session has a unique ID)
timestamp — epoch timestamp in milliseconds
pastedContents — pasted content (text, referenced images)

In my case, I asked it to try to identify the sessionId of the previous session by filtering by project and timestamp. With that, it was able to retrieve that history. Afterward, I asked it to explain exactly what step-by-step process it had followed, and I got the following response:

Useful fields: display — the text you typed sessionId — identifies the conversation (each session has a unique ID) timestamp — epoch timestamp in milliseconds pastedContents — pasted content (text, referenced images) What I did to recover it: I identified the sessionId of the previous session by filtering by project and recent timestamps I filtered all lines with grep "06df3b73-..." to isolate only that conversation I extracted the display field from each line Important limitation: history.jsonl only stores your messages (user input), not my responses. So I was able to reconstruct what you asked for, but not exactly what I replied — I inferred that from the commits and the current code.

This way, even without access to Claude Code’s responses, it still helps quite a bit to have a history of everything you asked it, which somewhat reduces the problems caused by starting a new session. In my case, it was able to fully understand my last request and implement it without any issues. I hope this helps in some way.

Same issue here.

yeah this is biting me using /loop ... get's stuck in 1 hour (running every 20 minutes)

Same. Error is not about individual file size it's the accumulated session context exceeding the 20MB API request limit.

Issue:

_Every image pasted/dragged into a conversation gets base64-encoded into the session JSONL file. Over an extended session with many screenshots, this grows unchecked._

Session Stats:

• Active session JSONL: 67MB (~/.claude/projects/.../0f6a4d7e-...jsonl)
• The image-cache directory was 12kb (Removed Images)
• Total project session data: 505MB across multiple sessions
• Compaction reduces text tokens but the base64 image payloads persist in the conversation history

Misleading Logging:

Error says "max 20MB" and implies the file you're operating on is too large, when it's actually the API request payload (conversation context + new operation) that's over the limit.

Workaround:

• Start a fresh session (/clear or exit and relaunch).

Fix:

• The error message should distinguish between "file too large" and "session context too large" they require very different user actions
• Images should be evicted or downsampled during compaction, since they're the primary cause of context bloat
• A proactive warning (e.g. "Session context at 80%")

Three hours of work and it's all ruined. I could puke.

Calling Claude code and making mistakes like first graders.

Someone needs to fix this ASAP, ruining a lot of things...

having the same issue, tried asking clause what was going on because my images were small and it just responded with the same cryptic 20mb message. Had to resort to google to find this thread. Would be good if Claude could explain the issue better.

ctrl +c and claude --continue can continue to run

Same issue here, for sessions that are not even that long-lived. The limit seems to be 32 MB now but it's the same issue.

Getting "Request too large" on a 99KB PNG after multi-day sessions is misleading — it is the accumulated session history, not the file, that is too large. Cozempic (https://github.com/Ruya-AI/cozempic) prevents this by pruning bloated session JSONL. Its guard daemon auto-prunes at configurable thresholds before you hit the 20MB wall, and the image-strip strategy clears accumulated base64 images that are usually the biggest offender. pipx install cozempic && cozempic guard to run it as a background watchdog.

How to fix this problem?

是的，这正在用 /loop 咬我...被卡住了 1 小时之内（之前每 20 分钟运行一次）

same as me