Skip to main content
  1. Articles/

Claude Code Gets a Restricted Mode — Because Autonomy Needs an Off-Ramp Too

·767 words·4 mins·
Florent Clairambault
Author
Florent Clairambault
CTO & software engineer — writing daily about spec-driven development and agentic coding

Claude Code Gets a Restricted Mode — Because Autonomy Needs an Off-Ramp Too

Claude Code v2.1.248 landed August 27 with a feature that cuts against the tool’s own reputation. This is the CLI that made its name by handing agents the keys — shell access, file writes, unattended multi-hour runs. Version 2.1.248 ships a mode that takes several of those keys back. That’s not a retreat from autonomy; it’s what autonomy actually requires once you’re running agents in contexts you don’t fully trust.

What restricted mode actually strips
#

The new --restricted flag (or CLAUDE_CODE_RESTRICTED=1 for the environment-variable crowd) does four specific things, per Anthropic’s own changelog:

  • Removes the built-in tools for running arbitrary commands or code, plus WebFetch
  • Keeps file tools scoped to the working directory — no wandering up the tree
  • Refuses bypassPermissions outright, even if a user or a script tries to set it
  • Ignores user, project, and local settings files entirely

That last two points are the ones worth sitting with. Most of Claude Code’s permission model is configurable — CLAUDE.md files, settings.json, allow/deny rules layered from user to project to local scope. Restricted mode is the first setting that can’t be overridden from inside the session it’s protecting. A CLAUDE.md file at the bottom of a repo can’t quietly re-enable bypassPermissions, and a malicious or careless settings.json can’t undo it either.

That design directly addresses a class of problem this blog has covered before: CVE-2026-21852, the CLAUDE.md-poisoning supply-chain attack that used exactly this kind of project-config trust to bypass deny rules. A settings file an agent reads is a settings file an attacker who controls that repo can write. Restricted mode’s answer is to stop reading it at all for the settings that matter most.

Who this is actually for
#

This isn’t aimed at the solo developer running Claude Code against their own machine — for that use case, the existing permission prompts and Auto Mode classifier (covered on this blog since its March rollout) already do the job. Restricted mode reads as infrastructure for the cases where Claude Code runs somewhere the operator doesn’t fully control the input: CI pipelines processing untrusted pull requests, self-hosted runners executing on behalf of external contributors, or any automation where the “session” is triggered by something other than a developer sitting at a keyboard giving live consent.

That framing lines up with the rest of v2.1.248’s release, which is otherwise an enterprise-infrastructure grab bag:

  • /usage-credits: lets Enterprise orgs on AWS Marketplace, self-serve, or trial plans request higher usage limits from inside the CLI instead of going through a support channel
  • Cross-session messaging on Windows: SendMessage/ListAgents between sessions on the same machine, previously mac/Linux-only, now works natively on Windows (Bedrock, Vertex, Foundry, or with telemetry disabled)
  • Self-hosted runner client labels: claude self-hosted-runner --client-label <label> overrides the hostname-based default, useful once you’re running fleets of runners that all resolve to similar system names
  • Server-managed settings diagnostics: /doctor and /status now explain why a settings fetch failed instead of silently falling back

None of these are headline features on their own. Together they read as Anthropic hardening the machinery around Claude Code for the fleet-of-agents deployment pattern rather than the single-developer one — the same direction signaled by Agent Teams, Dynamic Workflows, and the self-hosted runner support added across recent releases.

The fixes underneath
#

The release also carries a batch of reliability fixes that matter more than their bullet-point length suggests. Two of them are prompt-cache issues: tool definitions were re-rendering after OAuth token refresh, causing roughly one avoidable cache miss per hour in long sessions, and ScheduleWakeup’s tool definition could silently differ between a live session and a --resumed one, blowing the entire cache on resume. Prompt caching is one of the few levers that materially controls Claude Code’s cost at scale — an hourly miss compounds fast across a fleet of long-running agents, so this is a real cost fix wearing a bug-fix label.

The pattern
#

Every serious agentic coding tool eventually has to answer the same question: what happens when the agent runs somewhere you can’t personally vouch for the input? Restricted mode is Claude Code’s answer, and it’s structurally different from the permission systems most competitors ship — it’s not another rule you configure, it’s a mode that specifically can’t be configured away from inside the thing it’s restricting. That’s a small feature by line count and a real one by design intent: autonomy that scales to unattended, third-party-triggered contexts needs a floor that the agent itself can’t dig through, and this is Anthropic building one.

Sources: Claude Code changelog, fetched directly against the v2.1.248 (Aug 27, 2026) and v2.1.250 (Aug 28, 2026) entries.

Related