# Claude Code can now deny prompts instead of waiting > Claude Code 2.1.319 adds a setting that denies permission prompts so unattended work keeps moving. What changed on 6 November 2026 and what to check. Canonical: https://bridge-terminal.com/atlas/blog/claude-code-deny-instead-of-prompting-setting/ Last updated: 2026-11-07 Published 7 November 2026 · Plain English · What's new · 6 min read ## The short version - Claude Code 2.1.319, released 6 November 2026, added a setting, permissions.denyInsteadOfPrompting. An action that would have waited for a person's approval is refused, and the work continues. - Before, an agent running with nobody watching could sit stalled on an approval question. With the setting on, it is told no and moves on to the next step. - Anthropic's changelog says the setting applies in terminal sessions, subagents (helper agents) and teammates. - A refused action is not a finished task. Someone still has to read what was refused and decide whether to allow it. - Permission rules and the permission mode you chose should still come first. Anthropic's documentation for the older flag says only requests nothing else resolves are denied. Can Claude Code now keep working when it hits something it needs permission for, instead of freezing until you answer? Yes, if you switch on a new setting. In version 2.1.319, released on 6 November 2026, Anthropic added `permissions.denyInsteadOfPrompting`. An action that would have waited on an approval prompt is denied, and the work carries on. This is a small change, but it matters to anyone who leaves an AI coding agent running while they do something else. It turns "stuck waiting for you" into "told no, moved on". That is useful, but it also means some work can quietly not get done unless someone looks. ## What is new in Claude Code 2.1.319? [Anthropic's changelog](https://code.claude.com/docs/en/changelog) for 6 November 2026 describes the addition like this: "a tool call that would wait on a permission prompt is denied and the turn continues, in terminal sessions, subagents and teammates." A few terms, in plain English: - **Permission prompt.** The question Claude Code asks before it does something risky, such as running a command or changing a file. You answer yes or no. - **Turn.** One round of work: Claude reads your request, takes some steps and reports back. - **Tool call.** One action Claude takes, such as editing a file or running a command. - **Subagent.** A helper that the main Claude session starts for a side task. - **Teammate.** One of several Claude sessions working together on a job. So the setting says: when Claude is about to take an action that would normally stop and ask a person, refuse it instead and keep going with the rest. The same release made other changes, such as moving long-running jobs from connected tools to the background in the terminal, and a change to how "auto mode" (where a classifier reviews actions instead of you) behaves when telemetry or feature flags are off. This article is only about the permission setting. ## Why would you want an agent to refuse instead of ask? Think of a contractor you have told to work through the night. If they find a locked door, there are two ways it can go. They can stand outside until you wake up and open it. Or they can note "door locked, skipped" and carry on with the rooms they can reach. In an interactive Claude Code session, the first outcome is the usual one: the agent stops and waits. If you have left the room, or the question came from one of several helpers working in parallel, that part of the job does not move until a person comes back. With the new setting on, the second outcome applies. The agent is refused and the rest of the job continues. For work meant to run unattended, that is often what you want. ## Is this the same as the existing headless flag? Partly. Anthropic's documentation on [running Claude Code programmatically](https://code.claude.com/docs/en/headless) already describes a command-line option for runs where nobody can answer: ``` claude -p "Update the dependency pins and run the tests" --permission-prompts none ``` The docs say that with this flag, anything that would prompt is denied unless a hook (a small script that runs at set moments) allows it. Claude is told that nobody can approve the request and not to retry it, and the run continues. The flag needs Claude Code 2.1.259 or later. The docs also describe a permission mode called `dontAsk`, which denies every call that would otherwise prompt. It is aimed at locked-down automated runs. So refusing instead of asking was already possible for scripted runs. What the changelog adds is a setting, with the scope it names: terminal sessions, subagents and teammates. A setting can be saved in a settings file instead of being typed every time. Anthropic's page on [settings files and precedence](https://code.claude.com/docs/en/settings) lists four places a setting can live: - Your own user file, which applies to you in every project. - A shared project file, which everyone working in that folder gets if it is committed to the repository. - A personal per-project file, which applies only to you in that one project. - Managed settings, which an organisation deploys and which sit above all the others. One caution. The changelog line is the only description of this setting I could confirm. How exactly Claude is told about a refusal in an interactive session, and whether the setting also removes tools that need a person's answer (as the older flag does), is not stated there, so I have left those points out. Test it on a small job before relying on it. ## What does it not change? For the older flag, the documentation says permission rules and the permission mode you set still decide every call first, and Claude Code denies only the requests that nothing else resolves. It is reasonable to expect the same here, but the changelog line does not say so. If that holds: - If you already told Claude it may run a command, it still runs. - If you already told Claude it may never touch a file, that is still refused. - Only the "ask a person" cases change, from waiting to being denied. ## What does it mean for a team building software? ### Fewer stalled jobs, but more silent gaps A stalled agent is at least visible: you come back and see the question on screen. A refused agent can finish its turn looking tidy while a step it could not take was skipped. The risk moves from "nothing happened" to "something was left out and nobody noticed". For scripted runs, Anthropic's documentation describes a way to see this. With streaming output, denials appear as `permission_denied` messages, and the final result lists them. Whether other kinds of session keep a comparable list is not something I could confirm, so check the session output yourself. The practical rule is simple: if you switch refusals on, make someone responsible for reading what was refused. ### A refusal is a question, not an answer When an action is denied, the underlying need has not gone away. Maybe the agent needed to install a package, call an outside service or write to a folder you had not allowed. Each denial is a small request that a person should either grant, by adding a permission rule, or reject for a good reason. Treat the list as a to-do list for whoever owns the project's permissions. ### Good for helpers, with a catch The setting covers subagents and teammates, which is where stalls are hardest to spot. If one helper among five waits on a prompt that you never see, the whole job can drag. Refusal keeps the other four moving. The catch is that a helper that was refused may hand back partial work, so reviewing its result matters more. ### Who should turn it on? A sensible split: - **Turn it on** for overnight, scheduled or long parallel jobs where nobody is watching, and where you have already set permission rules for the routine actions. - **Leave it off** while you are still learning what an agent needs, or for risky one-off work where you would rather be asked. There the prompt is useful. - **Pair it with a morning check.** Someone reads what was denied before the work is called done. ## How does Atlas handle this? Atlas runs each of its AI engineers as its own Claude Code session, so permission behaviour matters to how they work. Atlas also puts limits around what counts as finished. A task is refused completion until its work is on main or queued for the landing train (the step that merges finished branches and runs the project's own checks), and until the product's rules pass. Production go-lives, spending, deleting data and sending anything outside are never decided for you. Showing what an engineer was refused, in plain words on the board, is coming to Atlas, built in, so it needs no setup on your side. Until then, if you run Claude Code yourself, set permission rules for routine actions first, test the setting on a small job, and read what was denied before you trust the result. You can read more about the team on the [Atlas home page](https://bridge-terminal.com/atlas/). ## Conclusion Claude Code 2.1.319, released on 6 November 2026, adds a setting that denies permission prompts instead of waiting for a person, in terminal sessions, subagents and teammates. It helps unattended work keep moving, and it shifts the risk from stalls to silent gaps. Use it where your rules already cover the routine actions, and have a person read what was refused. ## Questions people ask ### What does permissions.denyInsteadOfPrompting do in Claude Code? According to Anthropic's changelog for version 2.1.319 (6 November 2026), a tool call that would wait on a permission prompt is denied and the turn continues. It applies in terminal sessions, subagents and teammates. ### Does the setting let Claude do things without my approval? No. It does the opposite: requests that would have asked you are refused. The changelog does not spell out how it interacts with your rules, but for the older flag Anthropic says rules and the permission mode still decide first. ### How is it different from the --permission-prompts none flag? The flag is documented for non-interactive runs, needs Claude Code 2.1.259 or later, and tells Claude not to retry a denied request. The new setting is saved in a settings file and, per the changelog, covers terminal sessions, subagents and teammates. ### How do I know what was refused during an unattended run? For scripted runs with streaming output, Anthropic's docs say denials appear as permission_denied messages and the final result lists them. For other sessions I could not confirm a record, so check the session output yourself. ### Is it safe to turn on for overnight work? Refused actions simply do not happen, so nothing runs that you did not already allow. The risk is work left undone, so set rules for routine actions first and have someone read the refusals the next morning. ## About Atlas: Refused actions should never pass as finished work Atlas engineers are Claude Code sessions, and Atlas refuses to call a task done until its work is on main or queued for the landing train and the product's rules pass. Showing what an engineer was refused, in plain words, is coming to Atlas, built in, so it needs no setup. — https://bridge-terminal.com/atlas/ ## Sources - [Claude Code changelog (version 2.1.319, 6 November 2026)](https://code.claude.com/docs/en/changelog) - [Run Claude Code programmatically (--permission-prompts none)](https://code.claude.com/docs/en/headless) - [Claude Code settings files and precedence](https://code.claude.com/docs/en/settings) _Researched and drafted with Claude, then checked against the sources above. Atlas is an independent product, not affiliated with Anthropic or OpenAI._ ## Related - [Claude Code Can Now Block Writes Outside Your Project](https://bridge-terminal.com/atlas/blog/claude-code-block-writes-outside-working-directories/) - [Claude Code Permissions: Allow, Deny Rules and Modes](https://bridge-terminal.com/atlas/blog/claude-code-permissions-allow-deny-rules/) - [Claude Code Now Warns 10 Days Before Your Login Expires](https://bridge-terminal.com/atlas/blog/claude-code-login-expiry-warning-unattended/)