[BUG] Read tool renders same image content across different cached image files

Resolved 💬 3 comments Opened Apr 14, 2026 by davekim917 Closed Apr 18, 2026

Bug Description

The Read tool renders identical image content when reading different image files from the Claude Code image cache (~/.claude/image-cache/). Despite files on disk having different MD5 hashes and file sizes, the Read tool returns the same rendered content for all of them.

Environment

  • Claude Code version: (latest)
  • Platform: macOS (Darwin)
  • API: Anthropic API (user is using their own API key, not Claude Max subscription)
  • Terminal/Shell: zsh

Steps to Reproduce

  1. Paste image A into Claude Code chat → [Image #1] created at ~/.claude/image-cache/<session>/1.png
  2. Paste image B into Claude Code chat → [Image #2] created at ~/.claude/image-cache/<session>/2.png
  3. Paste image C into Claude Code chat → [Image #3] created at ~/.claude/image-cache/<session>/3.png
  4. Paste image D into Claude Code chat → [Image #4] created at ~/.claude/image-cache/<session>/4.png
  5. Ask Claude to describe each [Image #N]
  6. All [Image #N] references return the same rendered content — the first image pasted — despite each file having different MD5 hashes and sizes on disk.

Evidence

Session ID: d26cfe96-8eb9-4074-8b36-91dcdd6167ae

File hashes confirm files are genuinely different:

MD5 (1.png) = f04e9843ca84d39488740f12f192f62c  (182736 bytes)
MD5 (2.png) = 2e0d17c2e500f5d15a0148437b6a8a50  (95355 bytes)
MD5 (3.png) = 8584352e7ddeb4e529d5cfadf19c90da  (241190 bytes)
MD5 (4.png) = 1f3a6d5796454b1b9826b6f29e1730dd  (36971 bytes)

Yet Read tool returns identical conversation screenshot content when reading any of these files. The image cache path is:
~/.claude/image-cache/d26cfe96-8eb9-4074-8b36-91dcdd6167ae/

Additional Observations

  • The image URL in the chat message references minimax-algeng-chat-tts-us.oss-us-east-1.aliyuncs.com — but this is the user's own API infrastructure, NOT a Claude Code issue
  • The user is on their own API key, which means image caching behavior may differ from the Claude Max subscription flow
  • The session is using Opus 4.6 (claude-opus-4-6)

Root Cause Hypothesis

The Read tool's image rendering layer appears to resolve multiple distinct image cache files to the same rendered content. Possibilities:

  1. A session-level image index that maps [Image #N] references to a single canonical rendered image
  2. The rendering service collapsing all cache reads to the first image loaded in the session
  3. Some session state that overrides fresh image reads with a cached render of the initial image

Impact

  • Claude cannot reliably analyze multiple distinct images pasted in the same session
  • Each [Image #N] reference resolves to the first image instead of the intended one
  • This affects any workflow requiring comparison of or reference to multiple screenshots

Workaround

Use direct file paths (/read /path/to/file.png) instead of [Image #N] references. Reading directly from the user's Screenshots folder (/Users/davidkim/Screenshots/) works correctly — the rendering bug appears isolated to the image cache mechanism.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗