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

Status Closed — duplicate
Maintainer reply None cached
Activity 3 comments · opened Apr 14, 2026 · 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 ↗