{"version":"2.1.319","anchor":"permissionsdenyinsteadofprompting-is-now-a-restrictive-only","canonical_anchor":"permissionsdenyinsteadofprompting-is-now-a-restrictive-only","heading":"permissions.denyInsteadOfPrompting can only make Claude Code stricter","tier":"use","area":"Permissions","scope":"both","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.319\/e\/permissionsdenyinsteadofprompting-is-now-a-restrictive-only","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.319","markdown":"### `permissions.denyInsteadOfPrompting` can only make Claude Code stricter\n\n`permissions.denyInsteadOfPrompting` is now restrictive-only: project and local settings are ignored, and true in any allowed source wins\n\n**What**\n\n`permissions.denyInsteadOfPrompting` is now treated as a restrictive setting. A restrictive setting can only tighten what Claude Code is allowed to do. When it is on, any tool call that would normally ask you for permission is denied at once. A tool call is one action Claude takes, such as running a command. Claude is told about the denial and the turn carries on. This is what `--permission-prompts none` does for `-p`, but it applies to every kind of session.\n\n- Project and local settings are ignored for this setting.\n\n- If any allowed source sets it to true, it is on.\n\n- It only ever denies. It never approves anything.\n\n**Why**\n\nAn operator or managed settings can force Claude Code to deny rather than wait for an answer in any session. A project's own settings cannot switch that off.\n\n- Area: Permissions\n- Names: `permissions.denyInsteadOfPrompting`\n- Tier: Use it now\n- Useful: 4\/5\n- Signal: 2\/5\n- Scope: both\n- Heads-up: no"}