fix(web,mobile): new replies show overwritten local images#23212

Problem

An agent overwrites a local image, embeds the same path in a later reply, and the new reply displays the previous bytes until reload. Reproduced on Linux in the real web app with Claude: the PNG on disk was green while the new reply still rendered red.

Change

Key local image asset URLs by assistant message ID in web and mobile, so a new reply requests a fresh URL while chunks of the same reply share one entry. Strip the client-only revision before asset RPC calls. Existing callers without a revision keep their behavior. This does not snapshot image history or refresh an image overwritten within one message.

Include the synthetic PNG/SVG fixture data and stopped-server projection seed helper required to rebuild the evidence. No server contract or persisted app data changes.

Scope and approval

Fixes #15676 GitCafe: https://git.cafe/pingdotgg/t3code/issues/15676 Triaged bug via the automated issue flow: #15676. via-triage; requires Julius review for unavailable client surfaces. No auto-merge or land label.

Verification

• vp test run packages/client-runtime/src/state/assets.test.ts apps/mobile/src/state/assets.test.ts packages/client-runtime/src/state/runtime.test.ts: 28 passed across three files after merging current main.
• tsc-rs --noEmit in client-runtime, web and mobile: passed (client-runtime emits existing suggestions).
• Targeted lint, formatting and git diff --check: passed; lint reports existing mobile warnings.
• Capture proof chosen after the red-test step found that reproducing browser image reuse in existing test files requires substantial new asset-server/RPC scaffolding. Both reviewers agreed that a generic cache-key test would already pass on main and would not reproduce this bug.
• Primary current-head integrated pass: four loaded yellow images, overwrite the same path to magenta, request another real Claude reply; new reply magenta without reload, four earlier replies yellow.
• Two model reviews found no implementation bug. Full proof matrix is incomplete; this is not a claim of merge readiness. The central overwrite regression is supported in all four web recordings. Detailed limits follow.
• cannot-verify desktop, android, ios: Electron/Android unavailable; both EAS iOS builds failed resolving GhosttyKit. Streaming stability, reconnect/recovery, some default-revision callers, successful direct-image controls, and remote fallback remain unverified. The independent capture rebuild/pixel-delta check was not performed. Route these limits to Julius.

Provenance and rendering environment

• Captured base: b5a226e49c; captured feature head: 89ee147526. Captures were made 2026-10-22 approximately 00:19–00:43 UTC. Reflog places feature head at 2026-10-21 23:50:04 UTC and the later main merge 3098ef2f93 at 00:47:49 UTC. Old dev logs identify head checkout /home/ubuntu/wt/issue-15676 on web5817/backend13857 and base checkout /home/ubuntu/wt/issue-15676-base on web7881/backend15921; base reflog starts at b5a226e49c at 23:57:15 UTC. Existing metadata has no embedded SHA: attribution is reconstructed from checkout/reflog, launch logs and capture timeline, not cryptographically stamped at capture.
• Fixtures committed later as e76c41919d. All eight implementation paths are unchanged between captured feature head and the merge. Fixture commit changes only seed script/data. No evidence artifact is committed.
• Real web development app, T3 collaborative browser, Linux x86_64, Chrome/154.0.0.0, DPR 2. Reported CSS viewports: wide 1440×900 and narrow 390×844, each light/dark. Wide recordings are 2880×1800, but saved wide stills are 1280×800; narrow recordings/stills are 780×1688. Wide-still scaling/viewport discrepancy is unresolved and must not be described as exact 1440×900 still proof.
• Font: 16px / 24px -apple-system, BlinkMacSystemFont, "Segoe UI", system-ui, sans-serif (computed stack; installed face not recorded). Themes: light oklch(0.992 0 0), dark oklch(0.145 0 none). UI clock frozen at 2026-10-22 00:00 UTC for matching relative labels; timing marks use performance time, not frozen UI Date.
• Synthetic project and image files in isolated worktree state. R1–R4 are static projection fixtures cloned from app-written rows, not event-history proof. R5 comes from a real Claude Sonnet 5.5 turn through app commands. Same path overwritten in place; ordinary cache retained during each decisive sequence; no reload between overwrite and R5. Separate base/head sessions.

Paired endpoint index

diff0 is whole-surface absolute RGB difference amplified ×8 (black means equal); diffT is a magenta mask where maximum absolute RGB channel delta is >16/255. No crop/mask excludes surrounding UI. Counts below are pixels, not percentages. Endpoint differences can include layout/scroll/caret differences and do not themselves prove timing.

Narrow light uses base-narrow-light-settled.png. The earlier base-narrow-light-final.png shows Thinking with no R5 and is not the decisive before endpoint. Existing final-pair statistics already name the settled file; the packaging pass independently checked the matching diffs against it.

Before — narrow light, stale blue R5:

Before: new R5 remains BLUE v1 after same-path overwrite

After — narrow light, fresh yellow R5:

After: new R5 shows YELLOW v2 while earlier replies remain blue

Static boards and whole-surface comparisons

Recordings: steps and times

Times below are recovered marks in seconds from recording start; encoded duration is measured from the actual MP4. Marks are approximate and can diverge from encoded time after transport stalls/static-frame handling. Raw recordings are untrimmed. The overwrite happens through the fixture command outside the browser, so a colored transition alone does not document disk bytes; the script, metadata, reply labels and endpoint samples support that sequence.

Review sheets were regenerated during packaging directly from the current final *-recording.mp4 files (sampled 0%, 35%, 70%, 95%; not edited recordings). Old *-contact.png files are excluded from publication because one was stale. Sheets are sampling aids, not a claim that every intervening frame was inspected.

Current recording review sheet 1

Current recording review sheet 2

Current recording review sheet 3

Current recording review sheet 4

Honest matrix result

Supplement after merge and fixture commit

The primary agent independently reported a real-app no-reload check at e76c41919d on a 1280×800 browser: four loaded yellow images stayed yellow after same-path overwrite to RGB(208,0,208); a new Claude reply rendered magenta. The prompt itself also embeds magenta, so six elements represent four old replies, a user prompt and a new assistant reply. This is a supplemental still/pixel transcript, not paired-base evidence or a recording and separate from the paired recordings.

Primary check transcript

Supplement: old yellow reply, magenta user prompt, and new magenta assistant reply

Model and harness: Claude Opus 5.5 through the Claude harness (implementation); GPT-6.1-Sol through the Codex harness (triage, proof and PR), both models reviewed.

Evidence

Supersedes the earlier Verification, recordings, paired-endpoint and matrix sections above for the web rows they cover (W1, E1, and reply-1/reload/thread-switch behaviour). Those sections are kept unedited for the record. This round ran on 2026-10-22 against before = main 8d3b061121 and after = head f7082eceb. It used the real web app in headless Chromium driven by Playwright, with an isolated --home-dir and synthetic data only. Replies came from real Claude Haiku 5.5 turns. The image was overwritten in place (same inode), and reply 2 mounted 10.3 s (before) and 10.1 s (after) after reply 1's image loaded, inside the 5-minute query stale window.

Recordings, where an on-page overlay names the side, the SHA, the row and the elapsed time: before.mp4 · after.mp4

Colours are sampled RGB of each rendered image: BLUE (18,97,232), YELLOW (255,225,0). Readouts: before / after.

M2 endpoint, 1440×900 light. Before: reply 2 is stale BLUE.

Before, 1440 light: reply 2 still shows the old BLUE image after the file was overwritten

After: reply 2 is YELLOW and reply 1 stays BLUE.

After, 1440 light: reply 2 shows the new YELLOW image while reply 1 keeps BLUE

M2 endpoint, 390×844 dark: before / after

• Driver: driver.mjs, sha256 23d8d8ee7d697d1e0420c53b037dfa4e0e46b5a5d30d749238e9743804487ed7. Image helper: mkimg.py.
• What else changed: what-else-changed.md. The head forks from ed9b7ca9c5, and main is 39 commits ahead of it. http.ts, ChatMarkdownMedia.tsx and assetUrls.ts are identical between the two. The fileRevision that main adds (#23106) is not read on the chat image path. Even with that change, main still shows the stale image.
• Not covered:
  • Mobile (iOS/Android) is unverified. T3 device tools are disabled on the evidence host, and the EAS simulator cannot reach the dev server.
  • Desktop (Electron) is unverified. No Electron client was available.
  • Overwriting an image partway through a single streamed reply is out of scope, as stated above.