[BUG] Image attachment fails to decode/resize intermittently for visually identical JPEGs (same dimensions, same encoder

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

When attaching a screenshot (JPEG, 1220×2712px, from an Android device) to a Claude Code session, reading it sometimes fails with:
Codice
Unable to resize image — its pixels could not be decoded (the file may be damaged, or use an encoding Claude Code cannot read), and at 1220x2712px it is over the 2000x2000px limit, so it cannot be sent. Re-save it as a PNG or JPEG and try again.

This happens inconsistently: an older screenshot from the same device/app, sent the same way, loads fine; a newer one, attached identically, fails every time.
What I checked before reporting
I compared the working file and a failing file at the byte level (JPEG markers, ICC profile, Huffman tables):
Both are baseline JPEGs, 1220×2712px, 8-bit, 3 components — identical structure (JFIF + EXIF + ICC_PROFILE + 2×DQT + SOF0 + 4×DHT + SOS).
Both embed the exact same ICC profile, byte-for-byte identical ("Google Inc. 2016" sRGB, standard on Android screenshot pipelines).
file (libmagic) identifies both as valid, uncorrupted baseline JPEGs.
The only differences are content-dependent (Huffman table values, entropy-coded scan length, overall file size — ~645KB working vs ~866KB failing).
So this doesn't look like a device/OS-side encoding change (e.g. Ultra HDR / gain-map JPEGs) — the files are structurally equivalent, valid, standard JPEGs.
Steps to reproduce
Take a screenshot on an Android device (produces a 1220×2712px baseline JPEG with embedded sRGB ICC profile).
Attach it to a Claude Code session.
Result is inconsistent: sometimes the image renders inline successfully, sometimes it must be read via the Read tool and fails to decode/resize, even though the files are structurally identical valid JPEGs.
Expected behavior
A valid baseline JPEG of this size should be resized/decoded consistently, or the error message should point to the actual cause instead of suggesting file corruption/unsupported encoding when the file is neither.
Environment
Claude Code on the web / remote execution environment
Images ~1220×2712px, ~650–900KB, standard baseline JPEG with sRGB ICC profile (Android screenshot)
(Ho allegato due screenshot di esempio — uno che passa, uno che fallisce — stesse dimensioni e stesso encoder, per riprodurre il problema.)

What Should Happen?

A valid baseline JPEG (1220×2712px, standard Android screenshot with embedded sRGB ICC profile) should be decoded and resized consistently. Two screenshots from the same device, same dimensions, byte-for-byte identical file structure (same JFIF/EXIF/ICC/DQT/SOF0/DHT markers) — one loads fine, the other fails with "pixels could not be decoded" even though it isn't corrupted (verified with file/libmagic and by successfully re-decoding it in headless Chromium via canvas).
Either the resize step should succeed on any valid JPEG under normal size limits, or the error message should reflect the actual failure instead of suggesting file corruption/unsupported encoding when neither is true.

Error Messages/Logs

Steps to Reproduce

Take a screenshot on an Android device (produces a baseline JPEG, ~1220×2712px, with embedded sRGB ICC profile — standard Android screenshot pipeline).
Attach it to a Claude Code session (web/remote environment) as a file attachment.
Ask Claude to read/view the image.
Result is inconsistent across otherwise-identical files: sometimes it renders successfully, sometimes the Read tool fails with "Unable to resize image — its pixels could not be decoded..." even though the file is a valid, uncorrupted JPEG (verified independently with file/libmagic, and successfully re-decoded via headless Chromium canvas — see attached files: one working, one failing, same dimensions/encoder/ICC profile).

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2.1.278

Platform

Anthropic API

Operating System

Other

Terminal/Shell

Windows Terminal

Additional Information

No response

No source file or test is identified. Start by tracing the attachment and Read-tool image resize path associated with the reported error, then reproduce it with the provided working and failing Android JPEGs. Done means both valid baseline JPEGs resize consistently, or the failure reports its actual cause.