{"version":"2.1.282","anchor":"artifact-tool-stricter-consent-checks-and-a-cap-on-create-r","canonical_anchor":"artifact-tool-stricter-consent-checks-and-a-cap-on-create-r","heading":"Artifact tool: stricter consent, per-account approvals and one-time asks for notification-triggered reads","tier":"notice","area":"Artifacts","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.282\/e\/artifact-tool-stricter-consent-checks-and-a-cap-on-create-r","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.282","markdown":"### Artifact tool: stricter consent, per-account approvals and one-time asks for notification-triggered reads\n\nArtifact consent is now tied to your account, rechecked per action, and reads prompted by new-comment notifications need a fresh approval each time\n\n**Unclear.** What extra content is added to a new artifact's result, and which settings make the Artifact tool available, are not settled.\n\n**What**\n\nThe Artifact tool is the tool Claude uses to create, read and publish artifacts. Its consent checks, which decide when Claude has to ask you before acting, were tightened in several places:\n\n- The tool now refuses to act if the account or conversation changed after its permission check, or if that check is no longer on record. It says nothing was done and asks for a retry so the action is checked again.\n\n- Stored consent lists such as `artifactReadConsentSlugs`, `artifactOutsideOrgConsentSlugs` and `artifactAssetReadHumanConsentSlugs` are honoured only when `artifactConsentEpoch` matches the current `accountEpoch`, so switching accounts resets them. Consent is checked on each tool call.\n\n- Some asks can now be answered only by a person (`userOnly`). Sources used by `copy_from` are marked this way, and so is the general artifact read path.\n\n- A page-data read, a runtime-diagnostics verify or an artifact read triggered by the new-comments notification now gets its own ask, and approving it covers that one read only. Before, a page-data read with no matching ask rule could fall through to a session-wide approval. The verify trigger no longer depends on an extra condition.\n\n- Reading comments after a new-comments notification now returns \"Nothing was read\" when the artifact is not yet known locally, and asks once when no ask rule matched. The ask notes that comment text is written by artifact viewers.\n\n- A WebFetch of an artifact prompted by the new-comments notification now needs an explicit ask. In plan mode, or in a Cowork session where the user's own message did not start the turn, it is refused and Claude is told to raise it in chat.\n\n- The ask for artifact reads says it \"covers this url\" only when the matched rule starts with `url:`, and \"covers artifact reads\" otherwise.\n\n- `read_page_data` requests now carry the note \"requested after an unattended auto-reply notification\" when that applies, as `read` and `verify` already did. It appears in the permission description and in the summary the auto-mode classifier sees.\n\n- Read approvals now also cover `prompt` and `page`, and \"already approved\" applies to shared artifacts.\n\n- The result returned after creating a new artifact from a type is now capped in length, with extra content added to fill the remaining room.\n\n**Why**\n\nComment text on an artifact is written by other people, so a notification about new comments could otherwise pull outside content into your conversation, or earn a broad approval, without you deciding it. Expect more one-off permission prompts around artifact comments, and approvals that no longer carry over when you change accounts.\n\n- Area: Artifacts\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 2\/5"}