DEV Community

Cover image for Claude Code 2.1.316 Stops Asking Before Your Org's Managed Settings Apply
Gabriel Anhaia
Gabriel Anhaia

Posted on Edited on AI-assisted

Claude Code 2.1.316 Stops Asking Before Your Org's Managed Settings Apply

#claude #ai #devtools #security

Your company's Claude admin pushes a hook to every developer's machine. Before 2.1.316, Claude Code stopped and showed you a dialog first, naming what the policy wanted to run. The docs say: "Users must approve to proceed."

Claude Code 2.1.316, published on October 31, 2026, changes that for Team and Enterprise logins. The release note reads: "settings fetched from Anthropic's API now apply without an approval prompt, and a stored copy that doesn't verify is refused." Classmethod's write-up of the release files it under breaking changes.

The same release lets subagents run at a different effort level from your session. Both changes touch what runs on your machine and what it costs.

What the dialog used to catch

Server-managed settings are policy that an Owner or Primary Owner sets in the claude.ai admin console. Claude Code fetches them from Anthropic's servers at startup and polls for updates hourly.

Most of that policy never needed your approval. The approval list covered the risky subset. The docs name it:

  • settings that execute shell commands, such as apiKeyHelper, statusLine and otelHeadersHelper
  • sandbox settings that point at an executable, or that weaken isolation, such as sandbox.filesystem.disabled
  • delivered env variables such as proxy and base-URL variables
  • any hook definition

Under that model, every one of those raised a dialog in an interactive session. As of November 1, that page still describes the dialog; the docs haven't caught up with the release yet.

Editorial illustration of a sealed settings package with a gear on it rolling through an open checkpoint gate, the guard booth beside it empty
The checkpoint is still there. On Team and Enterprise logins, nobody stops the package at it anymore.

Be fair to the old dialog: it was never a veto you could work past. Per the docs, "If a user rejects the settings, Claude Code exits." Non-interactive runs such as claude -p and Agent SDK sessions couldn't show it at all, so approval-gated settings already applied there for that run only. What you lose is the notice: the moment you saw a new hook named on screen before it ran.

The other half of the note is a hardening. The docs' security table says that if a user edits the cached settings file, the "Tampered file applies at startup," until the next server fetch restores it. A stored copy that "doesn't verify is refused" reads like the fix for that row. The release note doesn't say how the copy is verified, or why the prompt was dropped.

See what your org sends you

If you sign in with a Team or Enterprise account, you can no longer rely on a dialog to tell you a new hook, helper or proxy variable arrived. Look at what is there instead. Update first:

claude update
claude --version
claude doctor
Enter fullscreen mode Exit fullscreen mode

In the claude doctor output, read the Managed settings (remote) line. The docs say it reports whether the delivered settings loaded, whether your org has none, or why the fetch failed or was skipped. It needs v2.1.248 or later. In a session, /status shows which managed source is active, and /permissions shows your effective permission rules.

The cached copy lives at ~/.claude/remote-settings.json, per the docs. Read it:

jq . ~/.claude/remote-settings.json
Enter fullscreen mode Exit fullscreen mode

Look for hooks, apiKeyHelper, statusLine, otelHeadersHelper, anything under sandbox, and the env block. Those are the keys the dialog used to put in front of you.

Don't plan on a hook of your own to watch this for you. The docs say ConfigChange hooks don't run "when server-managed settings arrive or refresh."

If you are the admin, your developers now get no on-screen notice when you add a hook. Tell them in the channel they actually read. Audit log events for settings changes are available through the compliance API or audit log export. The docs also say server-managed settings "operate as a client-side control, not a security boundary." That hasn't changed.

Subagents get their own effort default

The second change in 2.1.316 is CLAUDE_CODE_SUBAGENT_EFFORT, which sets "the effort level subagents run at when nothing else names one, instead of inheriting the session's."

That matters when you run the session high. The model docs describe xhigh as "deeper reasoning at higher token spend," and before 2.1.316 a session started with --effort xhigh handed that level to every subagent that didn't name its own. A test-runner subagent rarely needs that.

Editorial illustration of a large black silhouette turning a big orange dial to its highest notch, with three smaller silhouettes beside it each holding their own small dial set lower
Before 2.1.316, a subagent with no effort of its own took the session's level. Now you can give them a separate default.

Set it in the shell that starts Claude Code:

export CLAUDE_CODE_SUBAGENT_EFFORT=medium
claude --effort xhigh
Enter fullscreen mode Exit fullscreen mode

Classmethod tested exactly this split. With --effort high and the variable set to low, their run showed the main session at high and only the subagent at low. Without the variable, the subagent ran at high.

The variable is a default, not an override. A subagent's own effort frontmatter still wins, and so does an effort Claude passes for one invocation, per the subagent docs. To pin one agent, put it in the file:

---
name: test-runner
description: Runs the test suite and reports failures
tools: Bash, Read
effort: low
---
Enter fullscreen mode Exit fullscreen mode

One gap: CLAUDE_CODE_EFFORT_LEVEL overrides both frontmatter and per-invocation effort, but Classmethod notes the docs and changelog don't say which wins when it and the new variable are both set. Pick one per environment until that is documented.

The rest of 2.1.316 worth knowing

From the same release notes:

  • --restricted fix. Sessions started with --restricted could upload files from outside the working directories "when a Read allow rule covered them." If you use that flag to narrow what Claude can read, that alone is a reason to update.
  • An ultrathink off switch. CLAUDE_CODE_DISABLE_ULTRATHINK turns the keyword off, so the word can't raise effort for you.
  • Subagent model drift. Subagents that inherited a parent sub-agent's model could move to the main model when a background job or message woke them. That's fixed.
  • Opus 4.8 fast mode. Deprecated as of October 30 and scheduled for removal on November 30, 2026. After that, fast mode requests on Opus 4.8 "return an error and do not fall back." The platform release notes point to Opus 5.5.
  • Pooled budgets. The Claude apps gateway can now give a group one shared monthly budget, set with pooled_budget.

I haven't run 2.1.316 myself. The behavior above comes from the release notes, the docs and Classmethod's test.

Does your team want that approval dialog back, or was it noise everyone clicked through?

If this was useful

This post is about config rather than data, so I'll be straight about the fit. The Database Playbook is for the step after this one, when the subagents you just tuned start writing migrations and picking where your data lives. It covers choosing the right store for each system you build.

It's one of the Pocket Guides for Developers, 8 short books on agents, RAG, prompts, observability, events, databases and system design.

I also build Hermes IDE, so weigh this with that in mind: it runs Claude Code, Codex and other agent CLIs side by side, each in its own terminal and worktree. It's source-available (BSL 1.1), runs on macOS, Windows and Linux, and is on GitHub.

Database Playbook: Choosing the Right Store for Every System You Build

Top comments (0)