Attach a PNG or JPEG while Claude is busy with a turn - a 1800 by 1200 screenshot at 6.5 MB, say - and the steer fails with image errors. The conversation can then lose every later attachment on that turn. Attach the identical file to start a turn and it goes through fine. This is pingdotgg/t3code#20106.
Why it happens
Two halves meet in the middle. Images that start a turn get downsized before they are sent, but images queued into a running turn were sent at full size. On the client side, compression only looks at dimensions - anything already within the 2000px long-edge limit skips resizing entirely, so a file between about 3.75 MB and the attachment cap sails through untouched and arrives over the API's image size limit.
The dimension checks pass, so nothing warns you. The size only matters at the moment the bytes are sent, which is why timing decides whether the same file is fine or fatal.
The fix
Anthropic fixed the sending half in Claude Code v2.1.299 - the release notes call out images attached while Claude is working being sent at full size, which led to repeated image errors in long conversations. Clients that shell out to the user's installed Claude Code pick the fix up by updating it.
claude update
Until you are on 2.1.299 or later, attach images while Claude is idle rather than steering mid-turn, or keep them under about 3.7 MB. And if an image error does land mid-turn, start a fresh turn instead of retrying the attach - the old behaviour poisoned the rest of the conversation.