{"version":"2.1.251","anchor":"clearer-reasons-a-host-is-rejected-from-a-permission-rule","canonical_anchor":"clearer-reasons-a-host-is-rejected-from-a-permission-rule","heading":"Clearer reasons a host is rejected from a permission rule","tier":"notice","area":"Permissions","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.251\/e\/clearer-reasons-a-host-is-rejected-from-a-permission-rule","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.251","markdown":"### Clearer reasons a host is rejected from a permission rule\n\nRejected hosts in network permission rules now come with a plain-language reason.\n\n**What**\n\nWhen a host or URL cannot be used as the target of a network permission rule, Claude Code now explains why in plain language instead of just refusing.\n\n**Details**\n\n- Three reasons are produced: the value contains a wildcard, described as \"a wildcard, which srt matches against every host\"; it contains unsafe whitespace or control characters; or it is \"longer than a hostname can be\".\n- The validation helper runs unconditionally when a rule host is parsed.\n\n**Evidence**\n\n`longer than a hostname can be`\n\n- Area: Permissions\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 1\/5"}