Opus 4.7 regression: screenshot content fabricated from prior image in conversation

Resolved 💬 3 comments Opened May 5, 2026 by cchao-devo Closed Jun 2, 2026

Summary

On Opus 4.7 (Bedrock, us.anthropic.claude-opus-4-7), Claude Code describes a
newly-read image using content from a previous image in the conversation
rather than the actual pixels of the current file. The description is delivered
with full confidence and specific detail, making the fabrication hard to detect
without user pushback.

This feels like a regression from Opus 4.6, which in the same workflow did not
exhibit this cross-image confusion during a multi-hour pinchart testing session
the day before.

Environment

  • Model: Opus 4.7 (us.anthropic.claude-opus-4-7) via Amazon Bedrock
  • Claude Code: current stable (no /feedback because Bedrock, per CLI message)
  • OS: macOS (Darwin 25.4.0)
  • Context: Long session (20+ turns) reviewing multiple screenshots during a

live production test

Reproduction pattern

  1. Share Screenshot A with Claude (e.g., a tabular list view of resources).
  2. Have Claude describe Screenshot A correctly.
  3. Continue the conversation for several turns.
  4. Share Screenshot B, a structurally different view (e.g., a graph/canvas

detail page with a toast overlay) — different DOM structure, different
page layout, different colors.

  1. Ask Claude to describe Screenshot B.
  2. Observed: Claude describes the content of Screenshot A as if that were the

current image, with confident specific details (row count, column labels,
dates). The actual contents of Screenshot B (the graph canvas, the toast, the
chart preview) are missing from the description entirely.

The two view types shared zero visual structure — it is not a subtle-detail
misread.

Concrete example

During pinchart dashboard testing on a live staging environment:

  • Screenshot showed a task-output-view (workflow graph canvas on the left,

Task Details panel on the right with a chart preview, and an error toast at
the bottom).

  • Claude described it as a Pinned Charts list view with three tabular rows,

naming specific chart titles and timestamps that actually came from a
screenshot several turns earlier in the conversation.

  • This happened twice in the same session, despite an explicit self-correction

after the first occurrence (\"I will describe only what's in the current
pixels going forward\").

Why this is serious

When a user is troubleshooting production behavior and sharing screenshots as
evidence, a fabricated description corrupts their diagnostic process. Every
subsequent claim the user builds on that description is poisoned. The user
loses trust in all image-based reporting, which is especially damaging because
image review is a primary way UI state is conveyed to Claude.

The failure is also hard to detect automatically: single-image vision
benchmarks will not catch it, because the issue only emerges when a prior image
is in context.

Suggested investigation

  • Test multi-image conversations where each image is structurally different and

ask the model to describe each one. Measure drift toward describing earlier
images when the current one differs.

  • Compare Opus 4.7 vs Opus 4.6 on the same conversations. User observation in

this session is that 4.6 did not exhibit this pattern.

  • Consider whether visual-processing training optimized for single-image

benchmarks inadvertently weakened the \"re-read the current image each time\"
behavior.

Workaround

User added a hard rule to \~/.claude/CLAUDE.md\ to remind Claude to re-read
the file and describe only current pixels, and to name the file before
describing it. This is not a real fix — the model should not need the user
to install guardrails for basic perceptual accuracy.

Related

Announcement framing Opus 4.7 as having improved visual processing makes this
regression more surprising. Would appreciate an acknowledgment of whether this
behavior is reproducible on Anthropic's side and whether it's scheduled for
investigation.

View original on GitHub ↗

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