[BUG] Could not process image

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/12616
2. https://github.com/anthropics/claude-code/issues/13491
3. https://github.com/anthropics/claude-code/issues/12103

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

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.

Same! It totally crashes the session forever.

Still happening

<img width="717" height="165" alt="Image" src="https://github.com/user-attachments/assets/c2426d71-824e-426d-80b2-a70bee044ca4" />

<img width="892" height="74" alt="Image" src="https://github.com/user-attachments/assets/6fe31e1c-a442-4f5a-bcaa-c898c706bb7c" />

I've ran into this as well

It is bound to happen when you're working with images.

It is bound to happen when you're working with images.

Shouldn't be, the anthropic models are multimodal, and if they don't support that particular format the harness should convert.

Even still, I'd be happy if I didn't have to restart the session

Still hitting this in March 2026 — session-breaking with no recovery path.

Session cd7ba35b-379f-497c-880e-350c111d6ebe is permanently bricked. The API returns:

API Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"Could not process image"}}

Every resume attempt fails because the corrupted image is in the conversation history and gets re-sent on every request. There is no way to skip, remove, or edit the
offending message. The only option is to abandon the session entirely — losing all context, tool state, and progress.

This has been open since December with multiple reports and no fix or workaround. For a paid CLI tool where long sessions represent significant invested work, silently
bricking sessions with no recovery is a serious reliability issue.

Possible mitigations that would help immediately:

1. Skip unprocessable images on resume — drop or placeholder them instead of hard-failing the entire session
2. Expose a way to edit/prune conversation history — let users remove the offending message
3. Validate images at insertion time — fail fast when the screenshot/image is captured, not on every subsequent request

This affects anyone using screenshot tools, browser DevTools MCP, or pasting images into sessions. The longer this sits, the more sessions get lost. Please prioritize.

🔴 P0 request — still actively breaking sessions, March 2026. Open since December with no response.

cc @anthropics/claude-code-team

Impact: This is a data-loss bug in a paid product. Sessions with hours of accumulated context are permanently unrecoverable. There is no workaround, no way to edit
history, and no graceful degradation. Users lose everything and start over.

Session cd7ba35b-379f-497c-880e-350c111d6ebe — permanently bricked:

API Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"Could not process image"}}

The corrupted image is in conversation history → every resume re-sends it → hard fail loop → session is dead.

This affects core advertised functionality. Any session using:

• take_screenshot (Chrome DevTools MCP)
• Pasted images
• Any vision-based workflow

...is at risk of being permanently destroyed by a single unprocessable image.

Trend: Multiple reports since December, new ones still appearing. This is not an edge case — it's a ticking time bomb for every session that touches images. The report
count will only grow as more users adopt MCP tools with screenshot capabilities.

Suggested labels: bug, p0, data-loss, mcp, vision

Minimal viable fix (any one of these would help):

1. Catch and skip — on resume, drop unprocessable images instead of failing the entire request
2. Validate on capture — fail when the image is added, not on every future request
3. Session repair tool — let users prune broken messages from history

Three months open, multiple affected users, no workaround, lost paid sessions. This needs eyes. 🙏

Still reproducing on latest (March 2026) with HEIC files, but this affects any unprocessable image.

Traced the architecture. Three things compound here:

1. No format gate before persistence. Format detection from magic bytes fails on HEIC/HEIF, but the data gets sent to the API and written to the session JSONL anyway. No check against the supported format list before committing to history.

2. MCP mimeType ignored (#12009). MCP tools return a mimeType field with screenshots. Claude Code doesn't use it.

3. Failed images stay in history permanently. The bad image is in the JSONL before the API rejects it. Every subsequent message replays full history including the corrupt image. 400 every time. /exit and /resume don't help. Only /rewind works if you catch it early.

v2.1.70 and v2.1.72 patched adjacent issues (oversized images, read tool failures) but not the core loop: unprocessable image persisted, replayed, permanent failure.

Any one of these unblocks users:

• Validate magic bytes against [jpeg, png, gif, webp] before writing to JSONL.
• On API 400 "Could not process image", strip that image block from history before the next request.
• Honor MCP mimeType field instead of guessing format.

Update: The workaround hook now uses a subprocess proxy (v9) — instead of passing converted images to the context (which still accumulates), it spawns a fresh claude --model haiku to analyze each image and returns text only. Zero image data in context, unlimited reads per session.

Features: auto-context from session transcript, PostToolUse cleanup, prompt injection resistant.

Gist: https://gist.github.com/justi/8265b84e70e8204a8e01dc9f99b8f1d0

Stress-tested: 15 images in one session, zero errors.

---
cc @morphaven @adityuhkapoor @ahmadao2214 @edude03 @granvillebarker @zernie — updated workaround, now with subprocess proxy (unlimited images per session).

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.