What is dontAsk mode in Claude Code?

claude --permission-mode dontAsk

Also settable as permissions.defaultMode, but never reachable with Shift+Tab.

Answer

dontAsk auto-denies every tool call that would otherwise prompt you. Claude runs only what matches your permissions.allow rules, the built-in read-only Bash commands, and calls approved by a PreToolUse hook. It is the mode for unattended runs such as CI, where a prompt would hang rather than protect.

What it does

dontAsk answers every permission question with "no" instead of asking you.

claude --permission-mode dontAsk

Three things still run:

calls matching your permissions.allow rules
the built-in read-only Bash commands: ls, cat, echo, pwd, head,

tail, grep, find, wc, which, diff, stat, du, cd, and read-only forms of git

calls approved by a PreToolUse hook — a shell command Claude Code runs before

each tool call, which can approve or block it; see the example below

Everything else is denied silently. Claude carries on with what it is allowed to do rather than stopping.

Four things are denied outright, and an allow rule does not rescue them: calls matching your own ask rules, AskUserQuestion (the built-in tool Claude uses to ask you a clarifying question), connector tools your organisation set to ask, and MCP tools marked as requiring user interaction.

They share a shape: each one is a request for your attention. In this mode there is nobody to attend, so the request becomes a refusal.

When to use it

The mode is built for runs with no human attached:

CI pipelines, where a prompt hangs the job until it times out
scheduled or batch runs against a known set of commands
any automation where "ask the user" is not an available outcome

Paired with a tight permissions.allow list, it gives a session an explicit capability boundary: it can do these named things and nothing else.

When not to use it

Not for interactive work. Silent denials are confusing at a keyboard — Claude appears to skip things for no visible reason, and you lose the prompt that would have told you why.

Not as a security boundary against a hostile prompt, either. It restricts the tool calls Claude can make, which is a different thing from sandboxing the process.

Example

Run a non-interactive task with an explicit allow list:

claude -p "run the test suite and summarise failures" \
  --permission-mode dontAsk \
  --allowedTools "Bash(npm test:*)"

--allowedTools and permissions.allow are the same list by two routes: the flag for a one-off run, the settings file for a rule you keep. In .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(npm test:*)",
      "Bash(npm run lint)"
    ]
  }
}

The third route is a hook, which decides per call instead of matching a pattern — useful when the answer depends on the arguments rather than the command. Register it in .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/gate.sh" }
        ]
      }
    ]
  }
}

The script gets the call as JSON on stdin and answers on stdout. This one allows git reads and stays out of everything else, so the boundary holds:

#!/usr/bin/env bash
cmd=$(jq -r '.tool_input.command')
case "$cmd" in
  "git log"*|"git diff"*|"git status"*)
    echo '{"hookSpecificOutput":{"hookEventName":"PreToolUse","permissionDecision":"allow"}}' ;;
esac

Exiting with no output means the hook has no opinion — and here, no opinion is a denial. One limit worth knowing: a hook's "allow" does not override a matching deny or ask rule, so it widens the boundary rather than replacing it.

The mode itself:

claude --permission-mode dontAsk

It also works as permissions.defaultMode in a settings file, though a mode that silently refuses things makes an uncomfortable default — you meet it as work quietly not happening. One environment ignores the setting outright: cloud sessions on Claude Code for the web do not take dontAsk from settings files.

What you cannot do is switch into it mid-session: dontAsk never appears in the Shift+Tab cycle.

Common mistakes

Expecting an error when something is denied. Denials are not failures. Claude adapts and continues, which means a CI job can pass having quietly done less than you assumed. Check the output, not just the exit code.

Forgetting that ask rules become denials. A rule you wrote to force a prompt does not force one here — there is nobody to prompt, so the call is refused instead.

Assuming read-only means harmless. The built-in read-only Bash set still runs. It reads files, which on a machine with credentials in reach is not the same as doing nothing.