{"version":"2.1.317","anchor":"get-artifacts-route-added-to-an-allow-list","canonical_anchor":"get-artifacts-route-added-to-an-allow-list","heading":"A web route for artifacts joins a list of allowed routes","tier":"internal","area":"Artifacts","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.317\/e\/get-artifacts-route-added-to-an-allow-list","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.317","markdown":"### A web route for artifacts joins a list of allowed routes\n\nRequests to GET \/artifacts are now on a list of allowed web routes, in their own group apart from the deploy and upload routes\n\n**Unclear.** It is not stated what this allow-list controls, or whether anything a reader can reach uses the route yet.\n\n**What**\n\nClaude Code keeps a list of web routes it allows. A route is a kind of request paired with an address, such as a request to fetch (GET) a path. GET \/artifacts now appears on that list. It sits in its own group, separate from the \/deploy and \/upload routes.\n\n**Why**\n\nFetching from \/artifacts is handled as its own case rather than grouped with deploying or uploading.\n\n- Area: Artifacts\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 3\/5\n- Scope: individual\n- Heads-up: no"}