Unrecoverable session state when autonomous image Read fails with API 400

Summary

When Claude autonomously reads an image file (without being asked) and the API returns a 400 \"Could not process image\" error, the conversation enters an unrecoverable state. Every subsequent user message re-triggers the same 400 error, and the session cannot be rescued regardless of what the user types.

Steps to reproduce

1. Start a session working on a code task
2. Claude autonomously decides to read a PNG/image file (e.g. screenshots it hallucinated as existing, to understand visual state)
3. The file either does not exist or cannot be processed — API returns: {"type":"error","error":{"type":"invalid_request_error","message":"Could not process image"}}
4. User tries to redirect, ignore, or work around the error (e.g. "move on", "start over", "there is no image, stop erroring")
5. Every user message continues to produce the same 400 API error — session is permanently broken

Expected behavior

• Claude should not autonomously read image files it hasn't been asked to read
• If an API error occurs from a tool call, user input should be able to interrupt/recover from it
• At minimum, the session should degrade gracefully — the user should be able to continue with text-only interaction

Actual behavior

The conversation context is poisoned by the failed tool result. Every subsequent API call includes the broken image data and re-triggers the 400 error. The only recovery is to abandon the session and start a new conversation, losing all in-session context.

Environment

• Platform: Windows 11 (win32)
• Shell: bash via VSCode extension
• Model: claude-sonnet-4-6

Additional context

The user never requested the image reads. Claude invented screenshot filenames (e.g. s10_v19.png, s10_current.png) and attempted to read them autonomously to understand the visual state of a UI feature being developed.