{"version":"2.1.282","anchor":"webfetch-permission-checks-can-now-match-artifact-read-rules","canonical_anchor":"webfetch-permission-checks-can-now-match-artifact-read-rules","heading":"WebFetch and artifact-read permission rules can now apply to each other","tier":"notice","area":"Permissions","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.282\/e\/webfetch-permission-checks-can-now-match-artifact-read-rules","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.282","markdown":"### WebFetch and artifact-read permission rules can now apply to each other\n\nWebFetch permission checks can now match rules for reading artifacts, and artifact reads can be checked against WebFetch rules\n\n**Unclear.** It is not clear which checks supply the extra context, or exactly which rules cover which tool in each case.\n\n**What**\n\nWebFetch is the tool Claude uses to fetch a web page. Before it runs, Claude Code checks your permission rules, the allow and deny entries that decide what Claude may do without asking. This check used to look only at WebFetch `domain:` rules.\n\nThe check now works in two directions:\n\n- WebFetch: when extra context is supplied, the URL and prompt are first checked against the rules for reading artifacts, and then against `domain:` rules.\n\n- Artifact reads: the tool that reads artifacts can now be checked against WebFetch allow and deny rules.\n\n**Why**\n\nA rule you wrote for WebFetch may now also affect artifact reads, and the reverse. If you keep allow or deny rules for either, check that they still do what you expect.\n\n- Area: Permissions\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 2\/5"}