{"version":"2.1.268","anchor":"new-permission-request-fields-defaulttono-and-suppressalway","canonical_anchor":"new-permission-request-fields-defaulttono-and-suppressalway","heading":"New permission-request fields: defaultToNo and suppressAlwaysAllowRule","tier":"internal","area":"Permissions","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.268\/e\/new-permission-request-fields-defaulttono-and-suppressalway","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.268","markdown":"### New permission-request fields: defaultToNo and suppressAlwaysAllowRule\n\nPermission requests now carry defaultToNo and suppressAlwaysAllowRule fields from the server\n\n**Unclear.** What specifically triggers suppressAlwaysAllowRule to be set is not stated.\n\n**What**\n\nPermission requests (the prompts Claude Code shows before running a risky action) can now include two new pieces of information sent from the server: `defaultToNo`, and `suppressAlwaysAllowRule`. The second one is passed on internally as `askSuppressesAlwaysAllowRule` so that other parts of the code can check whether a given permission ask should skip offering an \"always allow\" rule.\n\n**Why**\n\nThis lets the server mark certain permission prompts as ones where you shouldn't be offered a blanket \"always allow\" option, presumably for actions considered too sensitive to auto-approve going forward.\n\n- Area: Permissions\n- Names: `defaultToNo`, `suppressAlwaysAllowRule`\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 3\/5"}