Unclear What the permission-asking behavior actually changes when turned on is not described in the finding.
What
- A new consent model for the Artifact tool, called "five-class asks," is being built behind the
CLAUDE_CODE_ARTIFACT_FIVE_CLASS_ASKSenvironment variable (off by default), which latches the behavior on or off for the life of the process and reports whether it was on via telemetry. - When enabled, it changes how Claude asks for permission on artifact actions:
- Pinning someone else's artifact to your own list is now auto-allowed instead of prompting.
- Uploading, reading (
list_assets/read_asset/list_files/read_file), commenting, and replying all go through a new classification system (pathAsk,readRule,flaggedSpelling,outsideAsk,hardLinked, plus anunknown/someone_else/from_type/cowrittensplit) and a new ruling flow, instead of always asking. - Uploads get an "already approved this session" fast path.
- Reading someone else's shared artifact can be auto-allowed via a per-conversation "class consent" latch, with the message "Reading ... needs no approval"; wording also changed from "another person's artifact" to "someone else's artifact."
- When the experiment is off, the previous single-path deny/ask logic is used unchanged.
Why
This reduces how often Claude has to interrupt with a permission prompt for routine, low-risk artifact actions, like pinning or re-reading something already approved, while still asking for genuinely new or risky ones.
Something disagreesSomething we can check disagrees with this entry, or the writer said they could not settle it.
The writer flagged doubt
What the permission-asking behavior actually changes when turned on is not described in the finding.