{"version":"2.1.282","anchor":"artifact-first-read-denial-now-also-covers-artifacts-of-unco","canonical_anchor":"artifact-first-read-denial-now-also-covers-artifacts-of-unco","heading":"Artifact read denials now say when ownership couldn't be confirmed","tier":"notice","area":"Artifacts","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.282\/e\/artifact-first-read-denial-now-also-covers-artifacts-of-unco","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.282","markdown":"### Artifact read denials now say when ownership couldn't be confirmed\n\nWhen no one can answer a permission prompt, the refusal to read an artifact now separates unconfirmed ownership from someone else's artifact\n\n**Unclear.** It is unclear exactly what condition triggers the new refusal and how the hook-based ask for WebFetch is decided.\n\n**What**\n\nSometimes nobody is available to answer a permission prompt, for example when Claude Code runs unattended. A permission prompt is the question Claude Code asks before doing something that needs your approval.\n\nIn that situation, Claude Code refuses the first read of an artifact. It now also refuses when one of your \"ask\" permission rules matches. The refusal message now separates two cases: an artifact whose ownership couldn't be confirmed, and an artifact that belongs to someone else. Before this change, the message always said it was someone else's artifact.\n\nReading an artifact through the WebFetch tool while network access is off also gains a way to ask for permission through a hook. A hook is a command you configure to run at certain points.\n\n**Why**\n\nIn sessions that run without anyone watching, the refusal message now says more precisely why the read was blocked.\n\n- Area: Artifacts\n- Tier: You'll notice\n- Useful: 1\/5\n- Signal: 1\/5"}