{"version":"2.1.274","anchor":"artifact-egress-probe-now-distinguishes-404-from-403","canonical_anchor":"artifact-egress-probe-now-distinguishes-404-from-403","heading":"Remote fetch checks now also recognize 404 as a non-fatal status","tier":"internal","area":"Artifacts","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.274\/e\/artifact-egress-probe-now-distinguishes-404-from-403","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.274","markdown":"### Remote fetch checks now also recognize 404 as a non-fatal status\n\nClaude Code's remote-fetch and artifact-fetch checks now treat HTTP 404 like they already treated 403, instead of failing\n\n**What**\n\nTwo places that fetch remote content used to only special-case HTTP 403 (forbidden) responses when deciding whether a failure was fatal:\n\n- The generic remote-config\/answer-fetch helper, used for things like skill or answer retrieval, now also checks for HTTP 404 using a new `omn` check before treating the response as an unrecognized status failure.\n\n- The egress probe used before fetching artifact content now also has a parallel 404 path (checking for a plain-text response with a \"not found\" reason), alongside its existing 403 (forbidden) check.\n\n**Why**\n\nPreviously a 404 response in these paths could be treated as an unexpected failure. Now it is recognized as a normal, non-fatal outcome, similar to how 403 was already handled, so Claude Code can respond to a missing resource more gracefully instead of erroring out.\n\n- Area: Artifacts\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 1\/5"}