Claude Code v2.1.319 shipped on November 6, 2026. In the release notes, three changes can affect a production harness. This article relies only on the release notes; I did not run anything.

Three changes

1. Background MCP tasks. When an MCP server runs a tool call as a task, Claude Code moves it to the background right away and tells Claude the result when it finishes. Set the environment variable CLAUDE_CODE_DISABLE_MCP_TASK_BACKGROUND to wait inside the tool call instead.

2. permissions.denyInsteadOfPrompting. A tool call that would wait on a permission prompt is denied and the turn continues. The notes say it applies in terminal sessions, subagents and teammates.

3. Auto mode server-side check. With telemetry or feature flags off, including behind LLM gateways, calls the server cannot check are asked about or denied, with no fallback to the built-in classifier. Set CLAUDE_CODE_AUTO_MODE_SERVER=0 to keep the old behavior. Bedrock, Vertex and Foundry are unchanged. Behind a gateway, CLAUDE_CODE_AUTO_MODE_SERVER=1 turns on the server-side check even with CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS set; if managed settings set the latter, they must set the 1 too.

Why it matters for a harness

In unattended runs (CI, scheduled jobs, subagents) a permission prompt is a point that waits forever if nobody is there. denyInsteadOfPrompting turns that wait into a denial so the flow keeps moving. The flip side is that a call a human used to approve may now fail quietly. The notes do not say how an agent handles a denied call (retry, work around, give up), so watch that yourself.

Background MCP execution keeps long tools from blocking the conversation. Because the result arrives later, check any order-dependent work that assumed the tool had finished. That is my inference, not something the notes state.

Three regression tests

These are proposals; I have not run them.

Case What to check
Call needing approval, setting off Does it still wait at the prompt as before
Same call, denyInsteadOfPrompting on Is the denial logged, and does the agent avoid an out-of-scope workaround
Long-running MCP task Does the result arrive after backgrounding, and does the env var make it wait

If you use auto mode behind a gateway, run the same set of calls before and after the upgrade and compare the ask/deny/allow distribution.

Limits

  • This article rests on the release-note wording only.
  • Behavior in specific gateway setups was not verified.
  • The notes contain no performance or safety numbers.

Conclusion

Permissions and background execution are areas where harness behavior shifts quietly. Before upgrading, pin three cases as regression tests: waiting for approval, denial, and a long MCP run. For earlier checks of this kind, see Claude Code 2.1.291 and permission reliability and MCP re-auth permissions.

Sources