Claude Code denyInsteadOfPrompting: Deny Permission Prompts Everywhere

Last updated: November 6, 2026

Claude Code 2.1.319 adds a setting that turns permission prompts into instant denials in every kind of session: put "denyInsteadOfPrompting": true under permissions in ~/.claude/settings.json (or pass it with --settings) and any tool call that would wait for you is refused, Claude is told, and the turn keeps going. Until now the only way to get that was claude -p --permission-prompts none, which covers print mode only.

The 2.1.319 changelog describes it in one line: "Added permissions.denyInsteadOfPrompting setting: a tool call that would wait on a permission prompt is denied and the turn continues, in terminal sessions, subagents and teammates." It is not on the settings docs yet, so the details below come from the setting's own description in the 2.1.319 settings schema and from runs I made against the 2.1.319 binary installed from npm.

What the setting does#

The schema description, verbatim in the parts that matter:

• "Never wait for a person to answer a tool permission prompt: a call that would prompt is denied at once, the model is told, and the turn carries on."
• "This is what --permission-prompts none does for -p, in every kind of session, subagents and agent teams included."
• "Allow rules, the permission mode, auto mode's classifier and PermissionRequest hooks decide first, as they do without it; it only ever denies, and allows nothing."
• "Read from user settings, --settings and managed settings; project and local settings are ignored, and true in any of those sources wins."

That last line is the security property. A repository cannot turn it on or off for you through its checked-in .claude/settings.json, and an organization can force it on through managed settings.

%% title: How a tool call is decided with denyInsteadOfPrompting on
flowchart TD
  A[Claude requests a tool call] --> B{Allow or deny rule matches?}
  B -->|Allow| R[Runs]
  B -->|Deny| X[Denied]
  B -->|No rule| C{Permission mode or auto mode classifier decides?}
  C -->|Allowed| R
  C -->|Would prompt| D{PermissionRequest hook answers?}
  D -->|Yes| E[Hook decision applies]
  D -->|No| F[Denied at once, Claude is told, turn continues]

How to turn it on#

For yourself, in ~/.claude/settings.json:

{
  "permissions": {
    "denyInsteadOfPrompting": true
  }
}

For a single run, pass it inline:

claude -p "Update the dependency pins and run the tests" \
  --settings '{"permissions":{"denyInsteadOfPrompting":true}}'

The value must be a boolean. When I passed "yes" instead of true, 2.1.319 refused to load that settings source and printed: --settings (inline JSON) (permissions.denyInsteadOfPrompting): Expected boolean, but received string. It also warns that nothing in that source is in effect, including hooks and permission rules, so a typo costs you more than this one setting.

What I verified#

Against @anthropic-ai/claude-code@2.1.319 from npm, in an empty scratch directory:

1. Denial. With only the setting on, I asked Claude to run touch proof.txt with --output-format json. The result listed one entry in permission_denials (tool Bash, command touch proof.txt), is_error was false, and no file was created. Claude's reply said the command needed approval and was denied automatically.
2. Allow rules still win. Same prompt with "allow": ["Bash(touch proof.txt)"] added next to the setting. permission_denials was empty and proof.txt existed afterwards.
3. Type check. "yes" fails validation as quoted above.

I did not test an interactive terminal session, subagents or agent teams. Those claims come from the changelog and the schema description.

Gotchas#

• Questions and plan mode go away. The schema says Claude's questions and plan mode's tools "are not offered to the model", and an MCP server's request for input "is cancelled unless an Elicitation hook answers it". If a workflow depends on Claude asking you something, do not enable this globally.
• Your SDK permission host is skipped. An app that answers prompts through canUseTool or --permission-prompt-tool "is not asked either". The schema's advice: answer from a PermissionRequest hook instead.
• A run of refusals ends the turn. The 2.1.319 binary logs a warning when a number of calls in a row are refused under this setting and ends the turn rather than letting Claude loop on denied calls. The threshold is not documented, so do not depend on a specific number.
• Auto mode billing notices. The binary also has a message for one case: when auto mode falls back to billed classifier requests that need a person's acknowledgement, calls that need the classifier are denied until the setting is off and the notice is answered.

When to use it, and the alternative#

Use it when nobody is watching and a hung prompt is worse than a denied call: scheduled jobs, background agents and teammates, and long auto mode runs where the classifier sometimes falls back to asking. Pair it with explicit allow rules for the commands the job needs, as in the permissions settings guide, and read permission_denials after the run to see what it wanted and could not do.

For a single claude -p run, the documented flag is still the shorter path. The headless docs show it with auto mode:

claude -p "Update the dependency pins and run the tests" --permission-mode auto --permission-prompts none

That flag requires Claude Code 2.1.259 or later. The other documented route is a mode, not a setting: per the permission modes docs, dontAsk "auto-denies every tool call that would otherwise prompt you" and is meant for locked-down CI with an exact allowlist. The difference is that dontAsk replaces your permission mode, while denyInsteadOfPrompting sits on top of whatever mode you run, auto mode included, and only catches the calls that mode would have sent to a prompt.

The new setting is what you reach for when the session is not a -p run, or when you want the behavior pinned in user or managed settings rather than repeated on every command line. If your unattended work lives in Anthropic's hosted scheduler instead, the trade-offs are in Claude Code routines vs managed agents schedules.

FAQ#

What does permissions.denyInsteadOfPrompting do in Claude Code?#

When it is true, a tool call that would wait for a person to answer a permission prompt is denied at once, Claude is told, and the turn carries on. Allow rules, the permission mode, auto mode and PermissionRequest hooks still decide first. It only ever denies. It was added in Claude Code 2.1.319.

How is it different from --permission-prompts none?#

The flag only applies to a claude -p run. The setting gives the same behavior in every kind of session, including interactive terminal sessions, subagents and agent teams, according to its description in the 2.1.319 settings schema.

Can I put denyInsteadOfPrompting in a project .claude/settings.json?#

No. Per the settings schema in 2.1.319, it is read from user settings, --settings and managed settings. Project and local settings are ignored, and true in any of the read sources wins.

Does it break AskUserQuestion and plan mode?#

Yes, by design. With the setting on, Claude is not offered its question tool or plan mode tools, and an MCP elicitation request is cancelled unless an Elicitation hook answers it.

Sources#

• Claude Code CHANGELOG, 2.1.319 - the setting's release note
• Claude Code headless docs: Turn off permission prompts in unattended runs - --permission-prompts none
• Claude Code CLI reference - the --permission-prompts flag and its 2.1.259 requirement
• Claude Code permissions docs - rules, modes and evaluation order
• @anthropic-ai/claude-code on npm - version 2.1.319, the build tested here

Continue Reading#

• Claude Code Auto Mode Explained - the classifier that decides before this setting does
• Claude Code Hooks Explained - PermissionRequest and Elicitation hooks, the way to answer instead of deny
• Claude Code Permissions Settings Guide - allow and deny rules to pair with it