[BUG] --resume fails with ECONNRESET when transcript contains large base64 screenshots; fresh sessions fine; stripping images fixes it (v2.1.201, macOS)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (closest: #74732, #74544, see "Related issues" below)
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

claude --resume <session-id> fails 100% of the time with API Error: Unable to connect to API (ECONNRESET) for a specific session whose transcript contains several large base64 screenshots, while fresh sessions on the same machine/network work perfectly. Stripping the base64 image blocks from a copy of the transcript makes the copy resume cleanly, so the images (payload size) are the trigger, not the network.

Environment

• Claude Code CLI v2.1.201
• macOS (Darwin 25.2.0)
• No VPN, no proxy, no ANTHROPIC_BASE_URL override
• Anthropic status page: all systems operational at the time

The affected session

• Transcript: 229 lines, 2.6MB JSONL, every line is valid JSON (validated with Python json.loads)
• Contains 6 tool_result blocks with base64 images (browser screenshots from Claude in Chrome), 300-400KB each, ~1.9MB combined
• Only ~19 minutes of conversation, nowhere near context limits (not a 1M-context session)

Repro / evidence

# Fresh headless call: works
$ claude -p "Reply with just: fresh-ok" --model haiku
fresh-ok

# Resume the affected session: fails, consistently (3/3 attempts, interactive and -p)
$ claude --resume <session-id> -p "Reply with just: resume-ok" --model haiku
API Error: Unable to connect to API (ECONNRESET)

The failure happens on the first request after resume, i.e. when the CLI replays the full conversation (including all base64 images) in one uncached request.

Confirmation that images are the trigger

I copied the session JSONL to a new UUID filename, recursively replaced every {"type": "image", "source": {"type": "base64", ...}} block with a small text placeholder, and rewrote the sessionId field on each line. File shrank from 2.6MB to 594KB. The repaired copy resumes successfully on the first attempt:

$ claude --resume <new-uuid> -p "Reply with just: resume-ok" --model haiku
resume-ok

Same machine, same network, minutes apart. The only difference is the image payload.

What Should Happen?

Resuming a session that Claude Code itself created (screenshots taken by the bundled Claude in Chrome tooling) should not brick the session. Ideas, in rough order of preference:

1. On resume, drop or downsample stale base64 screenshots from earlier turns before the first request (they are rarely needed verbatim after the turn they were taken in), or lazily elide them the way large text tool_results already get truncated.
2. If the request fails with ECONNRESET and the payload contains large image blocks, retry with images elided and surface a note, instead of failing hard.
3. At minimum, surface a real error ("request too large, N MB of images in transcript") instead of a generic connection error, and point at a recovery path.

Related issues

• #74732 reports --resume ECONNRESET on the same version, but there fresh sessions also degrade after a few turns; in my case fresh sessions are 100% healthy, and I have a deterministic in-transcript trigger plus a working repair, so this may be a more isolatable subcase.
• #74544 reports the same failure mode (large uncached replay causes ECONNRESET, recovery path also fails) for ~520k-token 1M-context sessions. Consistent with the same underlying "big first request after cache miss dies with ECONNRESET" behaviour; my report shows it also hits small sessions when images inflate the payload.

Workaround for anyone hitting this

Copy ~/.claude/projects/<project-dir>/<session-id>.jsonl to a new <uuid4>.jsonl in the same directory, replace base64 image blocks with a text placeholder, rewrite each line's sessionId to the new UUID, then claude --resume <new-uuid>.