[Bug] Read on mislabeled .png causes unrecoverable 'Could not process image' session corruption

Confirming another repro with concrete data. File 20a.jpg on disk was a 100KB HTML error page (likely a failed download saved with the wrong extension). When Read ran on it, Claude Code embedded the bytes as image/png in the tool_result, which then poisoned the session transcript — every subsequent turn replayed the bad block and got a 400 Could not process image.

Workaround that recovered the session without losing history:

1. Locate the session JSONL in ~/.claude/projects/<project>/
2. Validate each image block's base64 against the declared media_type magic bytes (PNG: 89 50 4E 47, JPEG: FF D8 FF, WEBP: RIFF, GIF: GIF8)
3. Replace mismatched blocks with a text block placeholder so the rest of the transcript stays intact

Fix ideas for the Claude Code side:

• Sniff magic bytes before wrapping Read output as image/*; fall back to text if bytes don't match the extension
• When a 400 Could not process image is returned, auto-quarantine offending blocks from the replayed transcript instead of hard-failing the session

+1, hit the same class of bug today on Claude Code with a different mislabeling shape — worth recording because it shows the issue isn't specific to "JSON-in-png", it's any non-PNG bytes behind a .png extension.

Repro

cp /tmp/something.bmp /tmp/preview.png    # rename only, contents still BMP
# Read("/tmp/preview.png")

Result:

API Error: 400 {"type":"error","error":{"type":"invalid_request_error",
  "message":"messages.55.content.36.image.source.base64.data: Image format image/png not supported"}}

After that every subsequent turn re-sends the same payload and gets the same 400. Session is dead until rewound.

Why this matters beyond the original report

The original issue showed JSON-text-in-.png. My case is actual image bytes (BMP) in .png — i.e. the file is an image, just not the format the extension claims. So the validation can't just be "is this a PNG / JPEG / GIF / WebP magic number" on the byte stream — but that's exactly the check that would have caught both cases.

A magic-number sniff in the Read tool before emitting an image content block (and falling back to a text/error block when it doesn't match a supported format) would fix the whole family.

Workaround I'm now using

Added a project-level rule: file <path> first, never cp a.bmp b.png, and normalize via PIL before Read:

python3 -c "from PIL import Image; Image.open('src.bmp').save('dst.png')"

But yeah, +1 on "the recovery side is the actual bug" — input validation should prevent it, but a single bad attachment poisoning the rest of the session is the part that turns a small mistake into a session loss.

@eltmon @jdinino @uraomotedo — the mislabeled-image class (ICO/HTML/other as .png/.jpg) you all hit is exactly what this hook mitigates. The subprocess proxy intercepts every image Read before it reaches the main session; invalid or mismatched formats fail inside a sandboxed claude --model haiku call and return text only — no malformed bytes ever touch the primary context, no thinking-block corruption, session stays alive.

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

+1, another repro on Claude Code 2.1.113 with a new mislabeling shape: stderr output from a screenshot CLI written to a .png file.

What happened

A file at docs/images/fold-current.png (14278 bytes) was created by a Windows screenshot CLI that wrote its warning text to the target path instead of PNG bytes — something like screenshot-cli > fold-current.png where the tool printed to stdout on error. Magic bytes on disk were 5b 57 61 72 6e 69 6e 67 ([Warning), not \x89 50 4e 47.

When Read was called on that path, Claude Code wrapped the bytes as image/png and sent them to the API. Result:

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

Session wedged — every subsequent prompt replayed the same tool_result and got the same 400.

Decoded preview of what got sent as image/png

[Warning] Multiple displays were found, but no display id was specified!
Defaulting to the first display found, however this default is not guaranteed…

So the "PNG" was a 14 KB ASCII error message. The extension was the only reason it was classified as an image.

Recovery

Used the same transcript-surgery approach @jdinino described — located ~/.claude/projects/<slug>/<session-id>.jsonl, found the single line containing the "type":"image" tool_result, replaced the image content item with a text stub (preserving tool_use_id so the pair stays matched), and also scrubbed the internal toolUseResult.file.base64 on the same line for cleanliness. claude --resume <session-id> after that unwedged the session without losing the preceding ~1000 turns.

Why this shape matters

The three earlier comments cover JSON/HTML/BMP-as-PNG — all "structured bytes with the wrong extension." This one is different: the file wasn't a format at all, it was a command's stderr output that happened to land at a .png path. It's a very common Windows/Unix pattern (tool writes error to stdout/stderr, user redirected to a file) and it produces the exact same unrecoverable state.

Both of the OP's suggested fixes would catch it:

1. Magic-byte validation in Read before emitting an image block (would see 5b 57 61 72…, fall back to text)
2. Drop the offending block from context on API 400 for image (would at least stop the poison-every-turn loop)

_"After that, the bad image stays in context and every subsequent turn fails with the same error. The session becomes unusable until I rewind the session history."_

Ah, THANKS for that insight. Makes total sense, and should be pretty fixable by the Claude Code folks?!

I had Claude harden my "Remote Control and Screenshotter" Java/Swing plugin, and also the script that invokes the HTTP call: The "RC server" validates that the file is >100 bytes, and that the first few bytes are correct magic, and then the shell side (rc.sh) runs file over it, identifying the type and validates that towards expected file ending - and file also "half loads" the image, producing e.g. "/tmp/mn-cur.png: PNG image data, 1200 x 720, 8-bit/color RGBA, non-interlaced" as output. If this fails validation, the script renames the file and produces an error output and exits non-zero - all so that the Claude instance doesn't just blindly tries to Read the file and end up in this situation.

Claude Code should do something similar: Actually load the image and ensure that it actually is an image file matching the file ending - before dumping it into context.

There could also be some belt-and-suspenders logic of chopping off that last message if the error 400 comes back from the server - so that one doesn't end up in this pretty hard-core, close-to-irreparable failure mode. I had to use /rewind and my only options were all of my "please try again" messages (all of which obviously just fails again), and then one WAY earlier in the transcript (choose "don't rewind files" in the options, and tell Claude what happened - it quite gracefully recovered..).

Confirming this independently from production — same root cause, different file content (SVG saved with .png extension).

Repro on our side

In an autonomous-agent setup (Paperclip's Claude adapter), an agent ran:

curl -o ./output/character-roughs-sheet.png https://example.com/path/to/attachment   # the URL actually served image/svg+xml

…then later did Read("./output/character-roughs-sheet.png") in the same Claude session. The SDK trusted the .png extension, packed the file as a base64 image/png content block, and persisted it into the resumed session jsonl (~/.claude/projects/.../<session-id>.jsonl).

From that turn forward, every wake of that session sent the same poisoned block back to the API and got:

400 invalid_request_error: Could not process image

…before the agent ever got a turn. The block stayed in the jsonl, so re-running the task didn't help. Only manual quarantine of the session jsonl (mv <id>.jsonl <id>.jsonl.poisoned-<run-id>) plus deletion of the local artifact unstuck it.

Blast radius (why this matters beyond the single session)

In an autonomous setup the failure isn't just "session unusable" — it cascades:

• 1 poisoned session → 4 stranded-task recovery jobs spawned by our supervisor (it observed the agent never producing output and treated each wake as a stranded run).
• Re-arming the issue, replacing source files, resolving blockers — none of it helped, because the poison lives in the SDK's session jsonl, not in any user-visible context.
• The supervisor / resume layer has no signal that the session is permanently broken vs. transiently failing — so it retry-loops indefinitely.

Fix priorities (echoing #47976 + adjacent issues)

Two surfaces, both worth fixing:

1. Validate magic bytes vs declared media_type at persist time in the Read tool (and any other path that converts a file into an image/* content block — Bash stdout, MCP tool-results). On mismatch, substitute a text marker like [image stripped: declared image/png, actual content image/svg+xml — original at <path>] instead of the image block. This prevents poisoning at the source.
2. Recover from a 400 Could not process image by stripping the offending image block from the persisted jsonl (or rotating the session with a forensic snapshot) instead of looping forever. Without (2), already-poisoned sessions in the wild stay broken even after (1) ships.

Related dupes / adjacent reports we found while triaging this internally: #13396, #39146, #44735, #47391, #47804, #28684, #53901, #56898, #11936, #15807. The class of bug is well-known in the tracker; this comment is just adding one more concrete production data point — autonomous-agent setup, SVG-as-PNG, multi-session blast radius — in case that helps prioritize.

Happy to share the quarantined jsonl (with sensitive tool output redacted) if it'd help reproduce.

This issue was fixed as of version 2.1.144.

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.