Follow Discord
Sweep 25 Sep 2026 · 19:33Z Build v2.1.283 504 read Stable v2.1.274 Latest v2.1.283 Next v2.1.283 Feeds RSS JSON llms.txt llms-full.txt Unofficial

Claude Code v2.1.282 ·

Artifact publishing reserves a name first and records which path it took

The Artifact tool now tries to reserve a slug before uploading, falls back to a server-assigned one, and records the publish path and omitted files

Group of 2 You'll notice Improvements
JSON All of v2.1.282
You'll noticeTier: how much it should matter to you
1Useful: my rating, 1 to 5
1Signal: worth watching, 1 to 5
ArtifactsArea: what it touches
ImprovementsKind: in v2.1.282,
ImprovementsSection of the release

What

When the Artifact tool publishes an artifact, it now works differently:

  • If the publish has no slug yet (the short name in the artifact's web address), the tool first tries to reserve one before uploading.
  • If the reservation fails, it writes a debug line ("could not reserve a slug before publishing") and publishes anyway, leaving the server to assign the slug. A 403 or 404 response on the reserve step is not reported as reserve_unavailable; any other failure is.
  • A 404 response on a redeploy is no longer always reported as multifile_unsupported; some of those 404s are now exempt.
  • A successful publish now records how many files were left out and which path it took: "preflight", "legacy" or "inline".

Before, a publish with no slug went straight to uploading.

Why

Publishes that start without a slug now try to get one before uploading, and still go through if that step fails. Fewer redeploy failures are reported as unsupported multi-file publishes.

How sure we are
Something disagreesSomething we can check disagrees with this entry, or the writer said they could not settle it.
The writer flagged doubtWhich "not found" errors on republishing are now handled differently is not stated.

See this entry in the whole of v2.1.282 →

Feedback