Claude Code 2.1.219

Claude Opus 5 (claude-opus-5) takes over as the default Opus model, with a 1M context window and fast-mode pricing of $10 in and $50 out per million tokens. Two things move with it: /fast no longer covers Opus 4.7 and now applies to Opus 5 and Opus 4.8, and the claude-api skill defaults to Opus 5 with a documented path over from Opus 4.8. A school switching to a new edition of a textbook works the same way: what you are handed at the start of term is the new one, but a reading list with the old ISBN written into it will order nothing. You get the new model without changing anything; only scripts with an older model id hard-coded need a second look.

You send one assistant off to do a job; halfway through it realises the work should be split between two more people — and until now it could not do that, it had to swallow the whole thing itself. Subagents can now spawn their own subagents, three levels deep by default, up from one. If you would rather not have work subcontracted down a chain, set CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH=1 to switch nesting off. The deeper ones are no longer a black box either: with --forward-subagent-text, subagents spawned at depth two and below show up in stream-json, keyed to the agent tool_use id that spawned them, so you can see who dispatched whom. Building trades subcontract the same way — one level used to be the limit, three is now allowed, and every level is logged against whoever hired it.

Workflows the system plans for you had no size guidance, so one task could fan out into dozens of agents running in parallel, leaving you unable to see the shape of it or estimate the cost. The default is now a medium guideline — aim for fewer than 15 agents — and it is advisory, not a hard cap. There are two ways to change it. Ad hoc: pick Dynamic workflow size in /config for another size or unrestricted. Permanently: set workflowSizeGuideline in any settings file, for example

{"workflowSizeGuideline": "medium"}

While a settings file specifies that key, the /config row hides itself so the two cannot disagree. A running workflow also shows the current size in its status line, with a pointer to /config if you want to change it. Think of a tour with no stated cap on group size: the absence of a limit is not freedom, it just means you find out how many people showed up when you get there.

When a command running inside the sandbox — the restricted area commands are confined to — tries to reach a host that is not on your allowlist, you used to get a prompt asking whether to permit it. In an automated run there is nobody at the keyboard, so that prompt is where the whole pipeline stops. The new sandbox.network.strictAllowlist setting lets you deny outright, without asking. To turn it on, add this to a settings file:

{"sandbox": {"network": {"strictAllowlist": true}}}

The nesting reads as one box inside another: sandbox contains network, and network contains strictAllowlist. It is a building switching to strict door policy — unregistered visitors simply do not get in, and the guard stops phoning upstairs to ask. Some visitors are turned away, but nobody gets woken at three in the morning.

When an MCP server would not connect, you knew it had failed and nothing more. Three additions here. claude mcp list and /mcp now report the HTTP status and error text, so an expired credential looks different from a mistyped address; and config values with hidden leading or trailing whitespace now raise a warning — the most maddening class of error, because the screen looks entirely correct. The headless stream-json init event gained mcp_server_errors, listing the --mcp-config entries that config validation skipped, and terminal runs print a startup warning too. A returned letter used to come back stamped only "undeliverable"; now the slip tells you which line of the address is wrong.

Centrally managed MCP allowlists and denylists often contain ${VAR} entries that get substituted at run time. The catch was where the substitution read from: the env block of a settings file — a file that sits in the user's own hands, which meant a rule set by an administrator could be rewritten by one local line. Those entries now resolve from the startup environment and the managed-settings env instead, and the settings-file env no longer participates. Think of dosage rules in a hospital: they used to be copied onto a whiteboard at each nurses' station, where anyone could rub a figure out. Now they are scanned straight from the system's master copy each time.

Halfway through a conversation you remember that another folder needs to be in scope, so you bring it in. The new DirectoryAdded hook wakes up at exactly that moment and notifies the tools around you. A new DirectoryAdded hook fires whenever a new working directory is registered mid-session — whether you type the /add-dir command or issue a register_repo_root control request via the SDK. Secondary tools learn right away that the folder list has changed. Think of an exhibition hall opening an extra booth mid-event: the moment the new space is registered, the information desk and public address system get an instant update so services can adjust without delay.

Operating something through another device, the thing you dread is the screen disagreeing with reality. Three such gaps in Remote Control are closed here. Remote Control clients no longer hold onto a stale fast-mode status after switching models, reconnecting, or failing an organization check. When the error "Remote Control is only available via api.anthropic.com" appears, the diagnostic text now explicitly names the specific setting that triggered it. Finally, running claude --teleport when your current checkout repository differs from the session's repository now prints which repository your current checkout actually points to. Like a remote cockpit dashboard: switch toggles update in real time, error lights pinpoint the exact faulty breaker, and location mismatches show the actual hanger where your vessel is parked.