Read tool: oversized images cause unrecoverable 400 loop after compaction

Bug

When the Read tool reads an image file that exceeds the API's 8000px dimension limit, the base64 data gets embedded in conversation context. After compaction, this data persists in every subsequent API call, causing an infinite 400 error loop that cannot be recovered from — the session is permanently bricked.

Steps to reproduce

1. Have a large image in the workspace (e.g., 9600x7734 px JPEG)
2. Use the Read tool to view it
3. API returns 400: messages.X.content.Y.image.source.base64.data: At least one of the image dimensions exceed max allowed size: 8000 pixels
4. Continue the conversation until compaction occurs
5. After compaction, the oversized image bytes are baked into the compacted context
6. Every subsequent API call fails with the same 400 error
7. User input, retries, "stop" commands — nothing works. Session is dead.

Expected behavior

The Read tool should check image dimensions (e.g., via sips -g pixelWidth -g pixelHeight on macOS or identify via ImageMagick) before sending to the API. If dimensions exceed 8000px in either axis, it should:

1. Return an error message to the conversation instead of the image data (e.g., "Image is 9600x7734 — exceeds the 8000px API limit. Resize first or use sips/convert to check dimensions.")
2. Never embed the raw image bytes into the context

Actual behavior

The image bytes are sent, the API rejects them, and after compaction the poisoned context makes the session unrecoverable. The user has to kill the session and start over.

Environment

• Claude Code v2.1.63
• macOS (Darwin 25.3.0)
• Image: 9600x7734 JPEG (~large logo file)