---
title: "Claude Code Gets a Restricted Mode — Because Autonomy Needs an Off-Ramp Too"
date: 2026-08-28
tags: ["claude-code","security","enterprise","agentic-workflows"]
categories: ["AI Tools"]
summary: "Claude Code v2.1.248 (Aug 27) ships a --restricted flag that strips exec and WebFetch tools, refuses bypassPermissions outright, and ignores project-level settings files — plus native Windows support for cross-session SendMessage and a new /usage-credits command for Enterprise. Verified directly against Anthropic's own changelog."
---


![Claude Code Gets a Restricted Mode — Because Autonomy Needs an Off-Ramp Too](/images/claude-code-restricted-mode-v2-1-248.png)

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](https://code.claude.com/docs/en/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 `--resume`d 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](https://code.claude.com/docs/en/changelog), fetched directly against the v2.1.248 (Aug 27, 2026) and v2.1.250 (Aug 28, 2026) entries.