Claude Code 2.1.319: auto mode tightens up, MCP tasks default to background
2.1.319 tightens permissions and auto mode on several fronts at once, moves long MCP tool calls to the background by default, and fixes a sandbox escape plus two permission bypasses.
2.1.319, released November 6, 2026, packs eighteen additions, twenty-two changes, sixteen improvements and ninety bug fixes. A thread runs through much of the list: permissions and auto mode tighten on several fronts at once, while long MCP tool calls get a faster default and move to the background right away instead of waiting. Three security fixes, including a sandbox escape, round out the picture. Everything else fits in two paragraphs.
Long MCP calls now default to background tasks
Until now, an MCP tool call still running after two minutes would automatically move to a background task instead of blocking the session, a mechanism the MCP docs describe this way: "An MCP tool call in the main conversation that is still running after two minutes moves to a background task instead of blocking the session." 2.1.319 adds a faster path: when an MCP server itself declares the call as a task, through the MCP tasks extension, Claude Code moves it to the background immediately, without waiting the two minutes, and tells Claude the result as soon as it arrives.
In practice, a report export or a build kicked off through a task-aware MCP server no longer freezes the session while it runs. To get the old wait-for-the-result behavior back, CLAUDE_CODE_DISABLE_MCP_TASK_BACKGROUND does the job: set to 1, it turns off this immediate handoff while leaving the two-minute backgrounding in place. MCP tasks now also work without feature-flag fetching (Bedrock, Vertex, Foundry, LLM gateways, DISABLE_TELEMETRY); to turn them off entirely, use CLAUDE_CODE_DISABLE_MCP_TASKS=1.
Auto mode now denies instead of falling back to the built-in classifier
Auto mode routes every action through a server-side classifier that blocks anything irreversible, destructive, or aimed outside your environment, on top of the explicit deny and ask rules that apply before it. That classifier needs to reach the server. Until now, when telemetry or feature flags were off, or behind an LLM gateway that doesn't relay that check, Claude Code fell back to a built-in classifier so it could keep running without prompts.
2.1.319 removes that safety net: an action the server can't verify is now asked about or denied, with no fallback to the built-in classifier. Bedrock, Vertex and Foundry are unchanged. Running auto mode with telemetry off should now mean more prompts than before on that kind of session, not fewer. To keep the old behavior, set CLAUDE_CODE_AUTO_MODE_SERVER=0. Behind an LLM gateway it works the other way with the same variable: CLAUDE_CODE_AUTO_MODE_SERVER=1 turns the server-side check on even when CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS is set, and managed settings that set the latter now need to set the former too. A narrower change closes another gap: a project's settings files or a plugin can no longer switch the server-side check back on once you've turned it off outside the project.
Permissions tighten, and three holes get patched
Several changes close blind spots in the permission system. The permissions docs note that Bash commands always require confirmation, "except a built-in set of read-only commands." 2.1.319 removes which followed by flags other than lookup or display ones from that set: the command now asks for confirmation again. A more structural tightening: when a session's exact ask rule for a Bash or PowerShell command coexists with a broader deny rule that also covers it, the deny rule now wins outright instead of falling through to a prompt. The Monitor tool's WebSocket watch now follows the same rule as any Bash command: a deny rule blocks it, and under an ask rule, an allow rule on Monitor, bypass mode, or auto mode is no longer enough to skip the prompt. And directories added with --add-dir now register their plugin marketplaces only once that directory's own trust dialog has been accepted, instead of loading them right away.
Alongside these behavior changes, three fixes patch real vulnerabilities. The Bash sandbox normally enforces its boundary "regardless of what the model chose to run"; 2.1.319 fixes a sandbox escape that occurred specifically when creating a worktree. A second fix closes a Bash permission bypass where a crafted environment prefix could hide part of a command from permission checks. A third stops a sed command from slipping past permission checks in accept-edits or auto mode. All three are fixed in this release with no configuration needed beyond updating.
Everything else
On the scheduling side, one change affects anyone running /loop without a fixed interval. Until now, an iteration that ended without rescheduling a wakeup triggered a fallback wakeup, as the scheduling docs still describe it: "If an iteration ends without either rescheduling or stopping, Claude Code schedules one fallback wakeup about 20 minutes later and ends the loop when that iteration doesn't reschedule either." 2.1.319 drops that fallback: the loop now ends as soon as a turn finishes without rescheduling. To keep the old behavior, set CLAUDE_CODE_LOOP_KEEPALIVE=1.
Two smaller additions are worth a line. /tasks gains an "Earlier in this session" row listing finished subagents, so you can reopen one and message it even after it drops off the list or you restart the session. And the new permissions.denyInsteadOfPrompting setting means a tool call that would have waited on a permission prompt is denied outright and the turn continues, in terminal sessions as well as for subagents and teammates, useful for a session that needs to keep moving with no one watching the screen. Everything else, the Claude apps gateway for enterprises, self-hosted runners, VS Code, Claude Tag, is mostly administrative or narrower in scope.
Pierre Rondeau
Developer and indie builder. I build products and automations with AI. Creator of Claude Hub.
LinkedIn