Image paste ID collisions after /compact cause wrong image to be referenced
Summary
[Image #N] paste IDs are session-local and the counter resets after /compact, so two different pasted images in the same session can both be tagged [Image #1] (or any N). When the model resolves an [Image #N] reference via the compacted summary, it can pick up the wrong image binary. The on-disk cache file (~/.claude/image-cache/<session-id>/<N>.png) is also overwritten when N collides, so the fallback path points to whichever image was pasted most recently under that number.
Claude Code version: 2.1.117
Platform: Windows 11 (native claude.exe)
Reproduction
- Start a Claude Code session.
- Paste an image. It's tagged
[Image #1]and saved to~/.claude/image-cache/<sid>/1.png. - Paste several more images (
[Image #2],[Image #3], ...). - Run
/compact. - Paste a new, unrelated image. It is also tagged
[Image #1]and overwrites1.pngon disk. The transcript JSONL'simagePasteIdsfield still records[1]for it. - Ask a follow-up that references the earlier
[Image #1]. The model conflates the two.
Evidence from my own transcripts
Session 9817be82-ad86-44df-bc27-dda94fd1bdd9.jsonl from ~/.claude/projects/. Each row is a user turn with an attached image — paste_id is the value of the imagePasteIds field on the record; SHA1 is the first 12 chars of sha1(base64 image data).
| Line | paste_id | SHA1 prefix | User message (truncated) |
|------|----------|-------------|--------------------------|
| 552 | 1 | 55a05f2937f1 | I don't see it [Image #1] |
| 2258 | 2 | b874e52e8c19 | no... there's 2 issues ... |
| 2316 | 3 | c32fd2c02048 | this is what I see from the desktop [Image #3] |
| 2421 | 4 | 3b496518b398 | I see it in desktop [Image #4] ... |
| 2735 | 5 | 2b2b2c9c23cc | why do I get these responses? [Image #5] |
| 3521 | 6 | c8139158797d | [Image #6] |
| 3525 | 7 | 8a4e51ca626d | here is that menu [Image #7] |
| (compact boundary around here) | | | |
| 4648 | 1 | 8f205e1a6477 (different image) | I only want new sessions [Image #1] |
| 4739 | 2 | 9e113dadfe03 (different image) | I see it! Some problems though... |
| 4794 | 3 | 3982abcb4530 (different image) | I see the new thread [Image #3] |
| 4865 | 4 | 1e4bd9ae2a01 (different image) | [Image #4] |
| 4900 | 5 | 6ce928eafddc (different image) | better! couple things to fix ... |
| 4941 | 6 | 7cf86b2f19e5 (different image) | still missing the last interaction [Image #6] |
| 4989 | 7 | 89ff38552055 (different image) | no... it got worse... |
| 5055 | 8, 9 | c8c6ce8c1e51, c3d6c3149906 | still not working... [Image #8] [Image #9] |
All seven paste IDs (1–7) get reassigned to different image binaries after compaction, inside one session.
What Claude Code writes to the transcript
Each paste produces two user turns in the JSONL:
// real data
{"type":"user","message":{"role":"user","content":[
{"type":"text","text":"[Image #1]"},
{"type":"image","source":{"type":"base64","media_type":"image/png","data":"..."}}
]},"imagePasteIds":[1], ...}
// meta follow-up with just a path string
{"type":"user","isMeta":true,"message":{"role":"user","content":[
{"type":"text","text":"[Image: source: C:\Users\<me>\.claude\image-cache\<sid>\1.png]"}
]}, ...}
Because N is reused across the compact boundary, the path \<sid>\1.png also resolves to different images at different points in the same session.
Expected behavior
Paste IDs should be globally unique within a session (monotonic across compactions), and cache filenames should reflect that. Either:
- Continue incrementing
Npast compaction, so[Image #8]is never reused, OR - Use a content-addressed filename (e.g., first 8 chars of sha1) instead of a counter.
Impact
Users hit "Claude is looking at the wrong image" when they paste multiple images in a long session, especially after /compact. Workarounds (single-image turns, /clear, absolute path references) are workable but obscure the root cause.
Environment
- Claude Code 2.1.117
- Windows 11 (native
claude.exebuild) - Image cache dir:
~/.claude/image-cache/<session-id>/<N>.png - Transcripts:
~/.claude/projects/*/*.jsonlwithimagePasteIdsfield on user records
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗