[BUG] Artifact publish: "identical content already refused ... resent unchanged" for content whose hash changed

Summary

Republishing an existing artifact from a local file is refused by two different gates, and the second one's message is factually wrong: it reports "identical content already refused ... resent unchanged" for content that demonstrably differs from both the live version and the previous submission.

Version: 2.1.233 (Claude Code), macOS arm64.

What I observed

Two refusals come from two different components. Grepping the running binary for each half of the two messages:

| String | Present in the 2.1.233 binary? |
| --- | --- |
| viewed the live version, counts as viewed, baseVersion | yes |
| identical content, resent unchanged, already refused, nothing was merged or published, use force:true only | no |

So the "hadn't viewed the live version" gate is client-side, and the "resent unchanged" gate is server-side.

Reproduction

1. Publish a local .html to an artifact. Later, from a new session, edit the file so it is a strict superset of the live version.
2. Artifact with url → refused: "You hadn't viewed the live version of this artifact". The full source is saved to a local file.
3. Artifact action:"read" on the same URL, then Read every line of that saved file.
4. Publish again → refused: "this is the identical content already refused against the newer version ..., resent unchanged."
5. Materially change the file (I bumped a version field and added a changelog entry; md5 changed from the previous submission).
6. Publish → refused again with "hadn't viewed the live version", which appears to burn the new content against the server-side gate.
7. read again, publish the changed content → refused with "identical content ... resent unchanged", although the content is not identical to anything previously accepted and differs from the live version.

Expected vs actual

• Expected: either the publish succeeds, or the refusal accurately describes why.
• Actual: the refusal asserts the content is identical and unchanged when its hash differs. Acting on the message as written ("merge your edits onto that version's source") cannot clear it, because the content already contains everything the live version has.

Things I ruled out by experiment

• Not file-path keyed — publishing the same bytes from a different path produced the same refusal.
• Not cleared by editing — a real content change (new hash) did not clear it.
• force: true works. That appears to be the only escape, and it is the correct outcome here since I had read and diffed the live version. It is also undocumented.

Why this matters

The message sends you to do a merge that is already done, and the only working escape is a flag that appears in no public documentation (Claude Code artifacts, Compliance API, support article). A wholesale supersede — republishing a document that is many revisions ahead — has no documented non-force path.

Suggestions

1. Make the message say what is actually true — e.g. "this content was already rejected in this session" — rather than "identical content".
2. Document force, and document the intended flow for a legitimate supersede.
3. Consider not recording a submission as "refused" when it was rejected by the client-side view gate, since the server never evaluated it.