[BUG] Large image attachment silently kills the session — no error written to transcript (Windows, v2.1.251)

Environment

| | |
|---|---|
| Claude Code version | 2.1.251 |
| Operating system | Windows 11 Home 10.0.26200 |
| Terminal | Windows Terminal / PowerShell |
| Is this a regression? | Unknown — first observed on this version |
| Date observed | 2026-08-30 |

Prior art

This has been reported before and closed without action both times:

• #72226 — same error string, macOS, v2.1.195. Closed not planned as stale by the inactivity bot, whose closing comment invites a new issue if still relevant. It is: this report is a newer version (2.1.251), a different OS, and carries the diagnostic detail the original lacked.
• #61091 — image attachments crashing sessions on Windows via a different mechanism (Bun segfault, v2.1.142). Also closed not planned. Noted because "image attachment kills the session on Windows" now has two independent causes on the record.
• anthropics/claude-agent-sdk-python#98 — the same 1 MB stdio JSON-RPC cap, in the SDK.

---

Summary

Attaching a large screenshot to a prompt causes the CLI session to stop responding permanently. No reply is produced, no error is written to the session transcript, and the only recovery is to kill the terminal and start over.

The failure is silent in a way that makes it unusually hard to report: because the session dies before an error record is written, a restarted session finds no trace of the crash in its logs. I could report only that "it froze," with no evidence to show — and Claude, inspecting its own logs afterward, concluded nothing had happened and that I must be mistaken. That cycle repeated across four sessions before we found the right place to look. That is the part I would most like fixed: the crash cost me a morning, but the missing error record cost me the ability to prove the crash existed.

Impact

Passing screenshots to Claude Code is how I show it anything that has no API — bank dashboards, POS reports, error states. My screen captures are 3840×1136, which puts every full-width capture over the limit, so the feature fails on essentially every real use, with no diagnostic and no hint that size is the variable.

Steps to reproduce

1. In the Claude Code CLI on Windows, attach a PNG whose base64 encoding exceeds 1,048,576 bytes (roughly >700 KB on disk).
2. Send the prompt.
3. The session hangs. No assistant response, no error surfaced in the transcript. Restart required.

Control: an attachment under the cap, in the same session type and environment, behaves normally.

Expected behaviour

Any of: downscale or re-encode the image to fit the transport; chunk the message; or fail loudly with an actionable message ("image too large, N bytes encoded, limit 1048576") that is written to the transcript and shown in the terminal. Currently it does none of these — it dies quietly.

Evidence

Four sessions on 2026-08-30, each ending on an unanswered user turn with no assistant record following:

| Session | Last turn (CDT) | Last turn content | Reply |
|---|---|---|---|
| session A | 10:59:01 | image, 3840×1136 | none |
| session B | 11:06:22 | image, 3840×1136 | none |
| session C | 11:13:38 | image, 3840×1136 | none |
| session D | 11:38:43 | text: "Jarvis, still with me?" | none |

The fourth is me typing into a terminal that had already died.

Source images, from C:\Users\<user>\OneDrive\Pictures\Screenshots 1\, sized against the 1,048,576-byte cap (base64 ≈ +37%):

| File | Dimensions | On disk | Base64 est. | Over cap | Session outcome |
|---|---|---|---|---|---|
| 2026-08-30 (3).png | 3840×1136 | 7.50 MB | ~10.27 MB | 10× | crashed |
| 2026-08-30 (4).png | 3840×1136 | 5.35 MB | ~7.32 MB | 7× | crashed |
| 2026-08-30 (6).png | 3840×1136 | 6.31 MB | ~8.64 MB | 8× | crashed |
| 2026-08-30 (5).png | 1923×1136 | 0.30 MB | ~0.41 MB | under | worked |

Across every session log on this machine (full session IDs available on request) for 2026-08-30, the count of error records of any kind is zero. The only isApiErrorMessage record in the two-day window is an unrelated "You've hit your session limit" from the previous afternoon.

Notes and open questions

• The transcript stores the attachment as a placeholder string in the user turn — [Image: original 3840x1136, displayed at 2000x592. Multiply coordinates by 1.92 to map to original image.]. The "displayed at 2000×592" suggests some downscaling already happens, yet the message still overflows. Either the resize is applied for display only while full-resolution bytes go on the wire, or the resized encode is still over the cap. Worth checking which — if a resize path already exists, tightening it may be a small fix.
• The attachment-type records adjacent to these turns are deferred_tools_delta entries, not the image payload, so the transcript never holds the image bytes.
• The error string (Fatal error in message reader: Failed to decode JSON: JSON message exceeded maximum buffer size of 1048576 bytes) appears in the terminal at the moment of the crash. It never reaches the transcript, so it is gone the moment the window is closed.

Suggested fixes, in order of value

1. Don't lose the error. Write the failure to the session transcript before dying, so a restarted session can see what happened. This alone would have saved several hours here.
2. Resize before encoding, to a target that keeps the encoded message under the cap.
3. Pre-flight check. If the encoded size will exceed the limit, refuse with a clear message naming the size and limit, and suggest reading the file from disk instead.

Workaround

Save the image to disk and give the assistant the file path; the Read tool pulls from disk and does not cross the stdio boundary. A 7.9 MB PNG reads without issue that way.