I have opened the log of an overnight job more than once to find the last line reading "waiting for confirmation." A person sitting next to it would have pressed Enter. Nobody was there, so it waited for hours.
The 2.1.319 changelog lists one new line aimed at exactly this wait: permissions.denyInsteadOfPrompting. This post is a design note written after reading that line and asking where I would use it. It is not a record of a verified run on my nightly jobs. Everything below rests on what the changelog says, and I'd rather tell you that up front.
What the changelog says (checked on November 8, 2026)
The primary source is a single line in 2.1.319.
| Item | What is written |
|---|---|
| Setting | permissions.denyInsteadOfPrompting |
| Effect | A tool call that would wait on a permission prompt is denied, and the turn continues |
| Scope | Terminal sessions, subagents and teammates |
| Not stated | The value type, the message the model receives on denial, any effect on exit codes |
When I fetched the settings reference, I could not find an entry for it. I read the value as a boolean, but I won't claim more than that. Please confirm the type in the documentation for your own version before relying on it.
The same release has a neighboring change. In auto mode, when a safety check can't be obtained and the action is refused, claude -p now exits with code 1 for both text and JSON output. That reports "no check was available" through the exit code, and it is a different mechanism from this setting. Keeping the two apart makes it easier to find the cause later.
Three ways to answer a prompt without a person
I sort the options into three.
| Approach | Who answers | What a stop looks like | Fits |
|---|---|---|---|
| Add allow rules up front | Rules you wrote ahead of time | No prompt appears at all | Fixed work whose scope you can state |
| Delegate to permission-prompt-tool | Your own decision tool | A ledger kept by that tool | Work where you want every decision recorded, or inputs rewritten |
| Deny with denyInsteadOfPrompting | Nobody; the call is refused and the run goes on | A failed tool call, then the turn continues | Work where unexpected actions may simply be declined |
The third option costs almost nothing. You build no decision tool and enumerate no rules. One setting removes the worst outcome, a job frozen until morning.
What changes is how failure looks. A prompt wait is a loud stop. A denial lets the job finish, with exit code 0 and everything, while the deliverable you wanted is missing. It no longer freezes. It quietly comes up short.
For cases where an allow rule seems ignored, I wrote up how to read six layers in /permissions. For compound commands that keep asking, see the cd and git prompt that repeats. My order is to exhaust the "don't ask at all" side first, then send whatever remains to denial.
Decide success by the deliverable
Denials happen silently, so I decided not to hand the success check to exit codes or log wording. The only question is whether the file the job should produce exists, with content in it.
The settings I have in mind look like this.
{
"permissions": {
"allow": ["Read", "Write(reports/**)"],
"denyInsteadOfPrompting": true
}
}Anything in allow goes through, and anything that would need a confirmation is refused without waiting. The launching script then inspects the output.
#!/usr/bin/env bash
# nightly-check.sh: decide success by the deliverable, even when denials let the run continue
set -u
OUT="reports/$(date +%F).md"
rm -f "$OUT"
claude -p "Write the delivery-data check results to ${OUT}" \
--allowedTools "Read" "Write(reports/**)" >/tmp/nightly.log 2>&1
CODE=$?
if [ ! -s "$OUT" ]; then
echo "No deliverable: ${OUT} (claude exit code=${CODE})" >&2
exit 2
fi
exit 0I delete the file first so a stale report can't pass for a fresh one, and -s rejects an empty file. Because the changelog doesn't document the denial message, I'd avoid grepping for its wording. That would likely break whenever the version changes.
Where I draw the line
I only let a job fall back to denial when being declined wouldn't hurt me the next morning.
Checking the delivery data of a wallpaper app and writing a report is that kind of job. If an unexpected write is refused, nothing is lost, and a missing report is caught by the script above. Work that deletes data or sends something outside can end half-finished if it simply moves on after a denial. I keep those on allow rules that state the scope, or on a decision tool that records each call.
Not freezing is not the same as succeeding. If you turn on denial, put the success check on the deliverable.
One next step
Open the log of your most recent overnight run and look for a single place where it stopped on a confirmation. If it's an operation you can describe precisely, add it to allow. If it's something you're fine having declined, that is your candidate for denial. I'd write the script that inspects the deliverable before touching the setting.