[Bug]: Image previews don't update when file updates#13138

Codex says this, it may be useful:

The chat preview reuses the same signed image URL when the file changes (ChatMarkdown.tsx). The server allows that URL to be cached for an hour (http.ts). Because the image’s src does not change, the browser can keep showing the old bytes.

The file preview panel avoids this by adding a workspace revision to its URL (FilePreviewPanel.tsx). The chat preview has no equivalent.

Confirmed. Expanded image reads in the thread are live lookups of the path, and the browser is allowed to keep the first response.

WorkLogEntryRow renders the viewed file with ChatMarkdownAssetImage (apps/web/src/components/chat/MessagesTimeline.tsx). That resolves to one media-file signed URL per path (resolveViewedImageAsset). The URL is cached client-side for 5 minutes, and image responses are sent with Cache-Control: private, max-age=3600 (assetResponseHeaders in apps/server/src/http.ts). The <img> src does not change when the file is overwritten, so later reads of that path keep painting the first bytes. Audio and video host files are already no-store; images are not. no-store alone would still not repaint an image that is already mounted.

The files tab avoids this. WorkspaceImagePreview appends workspace-revision from workspaceMutationId, which ChatView already updates after a completed file change or command. That id is not passed into the chat preview. Your note on ChatMarkdown.tsx, http.ts, and FilePreviewPanel.tsx matches this.

One extra trap for the fix: chat previews are media-file tokens pinned to device and inode (openMediaFile). The files tab uses workspace-file and re-resolves the path. Cache-busting the existing chat URL updates an in-place overwrite, but a delete-and-replace can 404 that token until it is signed again. The change should bump src with the workspace revision and re-sign (or serve the preview as workspace-file) when the workspace mutates. Same gap on mobile: renderViewedImage loads ThreadMarkdownImage from the signed URL with no revision.

Desktop is the shared web UI. No contract change. Cosmetic, and worth fixing so a second read of an overwritten image matches the files tab.

Still reproduces on 0.0.46-nightly.20261003.2632, and current main (98beed1a) has the same code path. Real case: an agent Reads /tmp/cur_small.png again and again while driving a phone. The agent's text describes the new screenshot (a YES/NO transfer dialog), but the expanded Read row shows an older capture. Only the UI is affected. The model gets the right bytes.

Root cause: a Claude Read image row is not drawn from the tool result. workEntryViewedImagePath → resolveViewedImageAsset (packages/client-runtime/src/work-log/presentation.ts) turns the row into a media-file { threadId, path } asset. That means:

• Every Read of the same path resolves to the same resource. The createUrl atom family caches it with ASSET_URL_IDLE_TTL_MS = 1h. The file response is also sent with Cache-Control: private, max-age=3600 (apps/server/src/http.ts). So later rows show whatever was loaded first.
• Without caching, every row would instead show the file as it is now. That is also wrong for older rows.

Suggested expectation: each Read row should show the bytes that call returned, not a newer version of the file. #16199 added tool-output-image { threadId, itemId, index } for MCP screenshots, and its notes say Claude Read rows "already show the file from its path". Serving Read images through tool-output-image (Claude stores the { source: { media_type, data } } shape that the parser already handles) would fix this, with media-file as a fallback only when the bytes weren't stored.

Following up from #21296, which I filed by mistake as a duplicate of this.

On serving Read images through tool-output-image: since #16652, the server no longer keeps those bytes. stripUnservedToolOutputImageBytes (apps/server/src/orchestration-v2/toolOutputImageBytes.ts) removes the base64 from a Read result before it is stored, because the row loads from viewedImagePath anyway. So that route means reversing #16652 for Read results under MAX_TOOL_OUTPUT_IMAGE_BASE64_LENGTH. Every viewed image would then be stored twice, once in the event log and once in the projection. Threads where an agent keeps re-reading a screenshot would grow quickly.

The scope cache key in #14943 avoids that cost, and it fixes the case in this report. The remaining gap is history: a row shows the file as it was when that row signed its URL, not the bytes the call returned. If the history gap matters, a cheaper option is to record a content hash at read time. A row could then say the file has changed since the agent viewed it, without storing the image.

Reproduced on Linux in the real web dev app at 3b95e7831b, using Claude Sonnet 5.5. Ran the red/read → green/read → blue/read sequence, expanded the Read previews, then overwrote the same PNG red and read it again. The new expanded Read row still rendered blue (RGB 0,0,255), while the PNG on disk was red (RGB 255,0,0). The agent received and described the updated image.

New Read row displays cached blue after red overwrite

Reproduced on 3b95e7831b: later expanded Read rows reused the first image URL. Fix and before/after recordings are in #23510. The final-head web replay displays red, green, then blue; 22 focused tests pass. Native iOS verification is blocked by GhosttyKit build errors on both baseline and head; Electron is unverified on this Linux VM.