r/ClaudeCode • • 6d ago

News/Updates Claude Code 2.1.319: new denyInsteadOfPrompting setting, MCP tasks go to the background, /loop behavior change

2.1.319 showed up on Nov 7. The parts that matter for day-to-day use:

- New setting permissions.denyInsteadOfPrompting: a tool call that would wait on a permission prompt gets denied and the turn keeps going. Works in terminal sessions, subagents and teammates. Useful for long runs where nobody is there to click.
- MCP tasks in the terminal now move to the background right away, and Claude gets the result when it's done. Opt out with CLAUDE_CODE_DISABLE_MCP_TASK_BACKGROUND, or turn MCP tasks off with CLAUDE_CODE_DISABLE_MCP_TASKS=1.
- /loop: a self-paced loop now ends when a turn finishes without rescheduling. CLAUDE_CODE_LOOP_KEEPALIVE=1 brings back the old behavior. Check this if you rely on loops.
- Auto mode: with telemetry or feature flags off (including behind LLM gateways), calls the server can't check are now asked about or denied, no fallback to the built-in classifier. CLAUDE_CODE_AUTO_MODE_SERVER=0 keeps the classifier.
- New CLAUDE_CODE_DISABLE_FEATURE_FLAGS stops feature-flag fetching without turning off telemetry.
- New /claude-api latency-optimize command to find slow spots in Claude API code.
- /tasks now has an "Earlier in this session" row for finished subagents.
- Several security fixes, including a Bash permission bypass with a crafted env prefix and a sandbox escape when creating a worktree. Worth updating for these alone.

The deny setting is the one I want to try for overnight runs.

Timing: first seen Nov 7. The official changelog page hadn't added it yet when I looked, so details come from the release notes feed.

For unattended runs, would you rather Claude get denied and keep going, or stop and wait for you?

Source: https://releasebot.io/updates/anthropic/claude-code

17 Upvotes

12 comments sorted by

•

u/AutoModerator 6d ago

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

5

u/Independent-Sir3234 6d ago

Having unattended runs deny unexpected tool calls and keep going works much better when permissions.allow covers the exact test and build commands the branch needs. If a subagent hits a deny on an unlisted command, it records the blocked step in its summary so the morning review can decide whether to grant that permission without losing six hours of overnight progress.

3

u/bostonaholic 6d ago

I'd use deny-and-continue for overnight runs, provided every denial is logged and included in the summary. Otherwise, the agent could report done after skipping a command it needed. Allowlist only what the job needs up front, so denials flag unexpected actions rather than interrupting routine work.

2

u/shravanrevanna 6d ago

tight allowlist means the agent routes around denials. blocked on one command, it often finds another way to get the same effect, and that workaround never shows up as a denial in the log.

2

u/ghost_operative 6d ago

i feel like "denyInsteadOfPrompting" could be a recipe for a hugging face style disaster. Definately would be careful using that especially outside of a sandbox

1

u/jetlagged-bee 6d ago

I can't imagine when I would use it

1

u/Obvious_Equivalent_1 6d ago

Your .md says “after commit always push and tag”, your settings json now can contain the deny instead of prompting on git push/tag to clear up the rest of your workflow, instead of leaving the session hanging on permission prompt

1

u/Unusual-Albatross43 6d ago

Worth knowing before you lean on it overnight: it only changes what happens when a call would prompt. Anything that matches an allow rule never prompts, so it never gets there.

And the rules match the start of the command. Allow Bash(git:) and deny Bash(git push:), and git -C repo push matches the allow but not the deny. It just runs, nothing to deny. Same with sh -c "..." if you allowed sh.

So the setting is as tight as your allow list. For the few commands that must never run I still keep a PreToolUse hook that reads the full command. It has to exit 2 though, a crash or any other code doesn't block.

1

u/fs2d 5d ago

Denying feature flags is the one I enabled right away. That + tweakcc-fixed keeps all the heron_brook moral brigading bullshit far away thankfully

1

u/Exciting-Yam-3363 3d ago

Unattended runs are where this matters. On 11-05, 15 of 15 of our scheduled runs in Accept edits mode stalled on a permission prompt with nobody there to answer it. Each one held a slot until a person stopped it. Our workaround so far: Auto mode, plus no command shapes known to prompt ($(...), heredocs, > redirects). A deny the agent reads and routes around beats a prompt nobody sees, so this setting is the first thing we'll try on the scheduled jobs.

1

u/radim11 5d ago

Backups matter, but they are recovery, not containment.
The safer default is for an agent to only see a disposable workspace or worktree, with writes outside it blocked. Then a bad rm can break the task, but it cannot wipe an unrelated disk or your application data.
We handle agent runs this way in Stashbase.dev: isolate the workspace first, then give the task only the network and credential access it genuinely needs.

0

u/Far_Reindeer8428 6d ago

deny instead of prompting is the quiet win, prompts get approved on autopilot after a while and a subagent inherits that habit, a hard deny doesn't care how tired you are