[BUG] [Cowork] Single artifact update writes 3 versions in 13s and keeps a stale one — silent loss of code added earlier the same day

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary

One artifact update produced three version files 13 seconds apart. The app
kept the third, which is missing a ~23-line function that existed in every
version saved earlier that day. No error, no warning, no user-visible signal.
The regression was only found later by byte-diffing version files.

Evidence

From Documents/Claude/Artifacts/<artifact>/versions/ (filenames are epoch-ms):

| file | time (UTC) | size |
|---|---|---|
| 1784642266729 | 2026-07-21 13:57:46.729 | 116 KB |
| 1784642272949 | 2026-07-21 13:57:52.949 | 144 KB |
| 1784642279793 | 2026-07-21 13:57:59.793 | 139 KB ← became live |

Total span: 13.06 s, from what was a single update from the user's side.

Every version saved earlier that day (09:41, 10:41, 11:37, 18:35, 18:50 SGT)
is 144 KB and contains the function. The 139 KB version that became live does
not. Diff of the 144 KB → 139 KB transition:

• window.VSSPLAN (~23 lines) removed entirely; all 10 call sites removed
• dayLow dropped from row objects in all three tab builders
• downstream records written with stop: null, target: null instead of

computed values

• UI legend text reverted to an older wording
• meta description field also reverted to an older revision

So the live file is not a partial write or a truncation — it is internally
consistent with an earlier state of the document, as if the update was
applied against a stale base and then written over the newer version.

The 116 KB intermediate was not inspected before it was superseded.

Impact

Silent data loss. The dropped function computed stop-loss and target values
for logged entries; without it, records are written with those fields null.
Nothing surfaced in the UI — the artifact rendered fine and the user had no
reason to check. Found ~2 days later by diffing on-disk versions while
investigating an unrelated issue.

The failure mode is the problem more than the specific loss: an update can
silently revert work with no signal, and the only way to detect it is manual
byte-comparison of version files.

Reproduction

Not reproducible on demand — observed once. The version files are on disk and
can be provided if useful. Filing because the artifacts are unambiguous and
the multi-write-then-keep-stale pattern seems diagnosable from the write path
without a repro.

Environment

Claude Desktop (Windows), Cowork, 2026-07-21. Same account and same app build
as #80365 (empty artifact mcp_tools allowlist), which began ~12 hours
earlier on 2026-07-21 01:41 UTC. Possibly the same underlying update; filed
separately as it is a distinct failure.

Note: the Artifacts folder is OneDrive-synced and I used Fable 5 to generate the artifact. Flagging in case it is
relevant, though all three versions are distinct app-written files with
distinct epoch-named filenames rather than sync conflict copies.

What Should Happen?

An artifact update should preserve all content present in the current version. If an update produces multiple writes, the final one should be the newest state, not a revert to an earlier revision. Content silently disappearing between saves should not be possible without a warning or error.

Error Messages/Logs

No error messages. The update completed silently and the artifact rendered normally; nothing surfaced in the UI. The loss was only discovered ~2 days later by byte-diffing on-disk version files.

Only on-disk evidence, from Documents/Claude/Artifacts/<artifact>/versions/ (filenames are epoch-ms):

1784642266729   2026-07-21 13:57:46 UTC   116 KB
1784642272949   2026-07-21 13:57:52 UTC   144 KB
1784642279793   2026-07-21 13:57:59 UTC   139 KB  ← became live

All three written within 13.06 s from a single user-initiated update. Every earlier version that day is 144 KB and contains the code that the 139 KB live version is missing.

Steps to Reproduce

Not reproducible on demand — observed once. Sequence as it occurred:

In a Cowork session on 2026-07-21, asked Claude to update an existing Live Artifact (a single-file HTML tool, ~144 KB).
The session had already run for some time with several prior updates to the same artifact that day (09:41, 10:41, 11:37, 18:35, 18:50 SGT — all correct, all 144 KB).
The update completed with no error; the artifact rendered normally.
On disk, three version files appeared 13.06 s apart from that single update: 116 KB → 144 KB → 139 KB. The 139 KB file became the live version.
The 139 KB version is missing a ~23-line function and its ~10 call sites that were present in every version saved earlier that day, and its UI text and meta description match an older revision.

Not verified at the time: whether the session had compacted before this update. If it had, this may be an instance of #69905 (agent regenerating from stale context) rather than an app write-path issue. Noting it so it can be ruled in or out.

Claude Model

Other

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Unknown build. Last correct artifact save: 2026-07-20 17:47 UTC. First bad: 2026-07-21 13:57 UTC. An auto-update occurred somewhere in that window.

Claude Code Version

N/A — not Claude Code CLI. Claude Desktop <version> (Help → About)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Cowork desktop GUI, no terminal involved.

Cowork Live Artifact, not Claude Code CLI. The version table and file sizes are in the Error Messages section above. Version files available on request as a sanitized diff or hashes — the raw files contain personal financial data.

Same account and build as #80365 (empty artifact mcp_tools allowlist), which began ~12 hours earlier on 2026-07-21 01:41 UTC.

Possibly related: #69905 (agent conflates own edits with pre-existing code after /compact) — the final file is internally consistent with an earlier document state rather than corrupted, which is more consistent with a regeneration from stale context than an interrupted write.