{"version":"2.1.248","anchor":"publishing-refuses-rather-than-silently-replacing-an-artifac","canonical_anchor":"publishing-refuses-rather-than-silently-replacing-an-artifac","heading":"Publishing refuses rather than silently replacing an artifact's icon","tier":"notice","area":"Artifacts","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.248\/e\/publishing-refuses-rather-than-silently-replacing-an-artifac","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.248","markdown":"### Publishing refuses rather than silently replacing an artifact's icon\n\nRepublishing without a favicon keeps the existing icon, or fails rather than swapping it.\n\n**What**\n\nWhen you republish an artifact without passing `favicon`, Claude now reads the existing icon to keep it, and if it cannot read it the publish fails instead of quietly falling back to \ud83d\udcc4. This is live in this build with no flag around it.\n\n**Details**\n\n- Two distinct failures: `favicon required to publish` with reason `missing_publish_field` when there is no existing page to read from, and a new `favicon_unread` reason when the page exists but its icon could not be read.\n- The fix in either case is to pass `favicon` explicitly.\n\n**Evidence**\n\n`couldn't read this Artifact's current favicon to keep it, so nothing was published \u2014 pass `favicon` explicitly`\n\n- Area: Artifacts\n- Names: `favicon`\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 2\/5"}