v2.1.172 made nesting 5 deep possible. v2.1.181 had to cap it.

What Shipped in the June 9-17 Sprint

Between June 9 and June 17, 2026, Anthropic shipped nine public point releases of Claude Code, its agentic coding CLI, from v2.1.170 to v2.1.181 . The Atom feed timestamps the window at just over eight days . That is the developer-facing read: a single sustained sprint, one model launch, and a long reliability tail.

The "nine" counts public-facing entries, not the numeric gap. The public versions are 2.1.170, .172, .173, .174, .175, .176, .178, .179, and .181; the skipped numbers are internal builds, so do not read the 170-to-181 span as eleven releases . June 12 alone carried three of them (.174, .175, and .176), all focused on governance and billing controls .

Four themes organize the window, and most releases serve more than one:

• Model access: v2.1.170 added Claude Fable 5, since suspended under a US export-control directive .
• Orchestration depth: v2.1.172 let sub-agents spawn sub-agents up to five levels deep .
• Permission governance: enforceAvailableModels and parameter-scoped Tool(param:value) rules arrived across .175 and .178 .
• Reliability sweep: edge-case fixes spanning macOS, Windows, WSL, Bedrock, Foundry, and network drives .

One detail captures the sprint's self-correcting character: v2.1.181 fixes a startup regression first introduced in v2.1.169, a build dated June 8 that sits just outside this window . The sprint closes a bug it inherited from the day before it began.

The June 9 Flagship: Launched, Then Suspended by Export Order

The sprint's marquee addition arrived first: v2.1.170 on June 9 gave Claude Code access to Claude Fable 5, which Anthropic describes as a "Mythos-class" model made safe for general use . The launch post priced Fable 5 and its sibling Mythos 5 at $10 per million input tokens and $50 per million output tokens .

Anthropic paired the model with routing safeguards. Certain cybersecurity, biology/chemistry, and distillation requests fall back to Claude Opus 4.8, and Anthropic projected that more than 95% of Fable 5 sessions would reach no fallback at all . The intent was a single high-capability default that quietly de-escalates only on a narrow band of high-risk prompts.

The CLI churn that followed traces almost entirely to this one model. Two releases stand out:

• v2.1.173 (June 11) normalized Fable 5 names with a [1m] suffix, because the model ships a 1M-token context window by default .
• v2.1.176 (June 12) made auto mode fall back to the best available Opus when Fable 5 was unreachable , a sign that availability was already in question.

It was. On June 12, Anthropic stated that access to both Fable 5 and Mythos 5 was suspended . A separate statement said a US government export-control directive forced Anthropic to disable both models for all customers. Every other Anthropic model remained unaffected, so the suspension was scoped to the Mythos-class tier rather than the platform.

The rationale is where the story gets unresolved. The directive appeared to cite a jailbreak concern, but Anthropic pushed back on that reading.

"The specific concern behind the directive was not provided to us," Anthropic stated, disputing the apparent jailbreak rationale for the suspension (source: Anthropic, Fable & Mythos access update).

For developers, the practical sequence matters more than the politics. A model went from default-available to globally disabled in roughly three days, and the CLI absorbed that volatility in code: the [1m] rename, then the Opus fallback path. If you wired a pipeline to Fable 5 between June 9 and June 12, v2.1.176's auto-mode fallback is what kept jobs running once the model went dark. Anyone who hardcoded the model name, rather than relying on auto mode, hit failures instead .

The v2.1.170 access note, in other words, has to be read alongside the June 12 reversal. The capability shipped; the access did not survive the week. What Anthropic has and hasn't disclosed about the model itself is a separate question, one this article returns to at the end.

5-Level Nesting in v2.1.172 and the v2.1.181 Chain Guard

The most significant orchestration change of the sprint was quiet: v2.1.172, on June 10, let sub-agents spawn their own sub-agents up to five levels deep . That turns a flat fan-out, one orchestrator delegating to N workers, into a recursive tree where a worker can itself become an orchestrator. The same release also made streaming tool execution always-on, so a deep agent's tool calls surface results as they run rather than blocking to completion .

Five levels is a lot of leverage to hand a non-deterministic planner. Each level multiplies the spawn count, and nothing in .172 bounded total chain length, only depth. A misbehaving plan that recursed instead of returning could expand without a hard stop.

The follow-ups read like a controlled tightening of that surface:

• v2.1.178 (June 15): auto mode now classifies subagent spawns before launch, so the orchestrator resolves the agent type up front instead of committing the call and discovering the shape later . The same release also made nearer nested .claude agents and workflows win on name collisions.
• v2.1.181 (June 17): a runtime guard was added against unbounded nested subagent chains, the practical enforcer of the depth ceiling first declared 11 releases earlier .

The changelog states it plainly:

"Added a guard against unbounded nested subagent chains." Claude Code changelog, v2.1.181 (source: code.claude.com/docs/en/changelog).

The sequence is the tell. A cap is announced in one release; an actual enforcer shows up eight days and roughly a dozen versions later, in the same release that also auto-hides idle subagent panels after 30 seconds and caps the visible list at five rows . That pattern (declare the limit, then retrofit the runtime check) usually means runaway nesting was observed in real sessions, not just modeled on a whiteboard.

For developers building agent fleets, depth is now genuinely usable up to five, but treat that as a budget, not a target. If your workflow relies on agents spawning agents, design for shallow trees and explicit return conditions; the runtime will now stop a chain that forgets to terminate, and you'd rather hit your own base case than its guard .

Scoped Permission Rules and enforceAvailableModels

Scoped permission rules let admins allow or block a tool call based on its parameter values, not just the tool class. Shipped in v2.1.178 on June 15, the new Tool(param:value) syntax with * wildcards means a rule like Agent(model:opus) permits a sub-agent spawn only when its model parameter is opus. Before this, a permission rule was all-or-nothing: a tool was either enabled or disabled for everyone who could invoke it.

That distinction matters for anyone running Claude Code under a shared policy. Previously, allowing the Agent tool meant allowing every model it could reach. Now you can permit cheap models broadly and gate expensive ones: Agent(model:opus) for the calls you want, a wildcard like Agent(model:*haiku*) for the rest, without writing a wrapper. The match operates on the call's actual arguments, so it composes with the parameter-scoped subtree loading that landed in the same release.

The model-governance side hardened over three consecutive releases. v2.1.175 added the enforceAvailableModels managed setting, which locks the Default model to an org-defined allowlist; user or project settings cannot widen those restrictions. v2.1.176 then tightened availableModels alias enforcement and added /fast model-restriction enforcement, closing two paths around the allowlist.

Read together, the pattern is a control plane for which models run and under what conditions. The timing is not incidental: this is the same window in which Fable 5 was launched and then pulled, and availableModels churn (alias normalization, allowlist enforcement, the suspension fallback to Opus) ran through several of these point releases. For a regulated org, the migration is to set enforceAvailableModels centrally and express model gating as parameter rules rather than per-user trust.

One caveat for teams adopting this now: parameter matching keys on the argument value as sent, so audit your aliases. If a model can be referenced by more than one name, a rule that lists one alias won't catch the other, which is exactly why v2.1.176's alias tightening shipped alongside the allowlist work.

Inline Setting Overrides, Presence Suppression, and Sandboxed Events

v2.1.181 also shipped three quality-of-life controls that change how you steer a session without touching JSON. The most reached-for is /config key=value, which sets any setting inline from interactive mode, -p, or Remote Control . Running /config thinking=false flips extended thinking mid-task, with no file edit or restart needed.

This matters for ephemeral and scripted runs. In a -p headless invocation you can now pin behavior per-command rather than maintaining a settings file the call has to inherit. For Remote Control, it means changing a setting from your phone without SSH-ing in to edit config.

The second addition targets notification noise. CLAUDE_CLIENT_PRESENCE_FILE points at a marker file; while that file exists, mobile push notifications are suppressed . The intent is narrow and useful: a shell hook or editor can touch the file when you're at the keyboard and remove it when you walk away, so you stop getting pinged on your phone for an agent you're already watching, without disabling mobile alerts entirely.

Third, sandbox.allowAppleEvents is an opt-in macOS setting that permits sandboxed commands to send Apple Events . Apple Events are how macOS apps script each other, so this opens a path from inside the sandbox into native automation: Notes, Finder, or a build tool can be scripted from within it. It stays off by default, which is the right posture: an agent that can drive arbitrary local apps is a wider blast radius than file edits, so you turn it on per-project when you actually want that bridge.

Spend visibility improved earlier in the window. v2.1.174 (June 12) reworked VS Code /usage to break spend out over a 24-hour or 7-day window, with per-category detail across cache-miss, long-context, subagent, skill, agent, plugin, and MCP usage . For teams now running deep agent trees and many MCP servers, that itemization answers the question a flat token total can't: which mechanism is actually driving cost.

None of these are headline features, but together they point in a clear direction: give developers finer, lower-friction control over a session's behavior, attention, and reach into the host machine, rather than forcing every adjustment through a config file edit and reload.

Startup Tax Removed, Network Drive Corruption Patched, Drops Handled

Most of v2.1.181's payload is reliability work, and the highest-value fixes target failures developers rarely notice until they cost data or time. The release removes a roughly 120ms startup delay introduced by v2.1.169, plus a separate hang of up to 15 seconds that struck on degraded networks . The startup delay was a regression; the network hang was a long-standing edge case. Both are now gone.

The most significant fix addresses silent data loss. Write and Edit operations could produce 0-byte or truncated output on network drives and cloud-synced folders, meaning anyone editing files on a mounted volume or a Dropbox/iCloud-style directory could lose work without an error . For agentic tooling that writes files autonomously, a corruption bug that fails quietly is among the worst classes of defect. This patch alone justifies the upgrade for teams on mounted storage.

v2.1.179 (June 16) handled a related resilience problem one release earlier: mid-stream connection drops now preserve partial responses instead of discarding them . Combined with the auto-retry on mid-thinking disconnects shipped in v2.1.181, the CLI now degrades gracefully on flaky links rather than throwing away in-flight work.

The remaining v2.1.181 changes span runtime and housekeeping:

• Bun runtime bumped to 1.4: the bundled JavaScript runtime moves up a minor version .
• Line-by-line streaming: long paragraphs now stream as lines arrive rather than waiting for the first line break, so output appears sooner .
• Spotlight TUI freezes resolved: a macOS interaction that could lock the terminal UI is fixed .
• 30-day history loss fixed: long sessions no longer lose history to the 30-day cleanup routine .
• Corrupted .claude.json null entries: malformed null project entries that could break config loading are now repaired .

None of these are capabilities you would put in a release headline. But the pattern matters: the sprint closed with a deliberate sweep of the failure modes that erode trust in an autonomous tool: lost writes, dropped connections, frozen sessions, and slow starts. For developers running Claude Code unattended against real codebases, durability is the feature.

The Suspended Flagship: What Anthropic Has and Hasn't Disclosed

Fable 5 remains the sprint's biggest unknown. Anthropic has not published its architecture, parameter count, context-window internals, independent benchmarks, or any benchmark methodology, neither in the Claude Code CLI notes nor in the June 9 launch post . What developers got was a price and a safety posture, not a spec sheet.

Here is what the record actually supports:

• Price, not specs. Fable 5 and Mythos 5 launched at $10 per million input tokens and $50 per million output tokens on June 9, with safeguards routing certain cybersecurity, biology/chemistry, and distillation requests to Claude Opus 4.8 .
• The [1m] suffix is cosmetic. v2.1.173 normalized Fable 5 names with a [1m] tag because the model ships a 1M context window by default, name normalization, not a distinct variant .
• A wider tier is implied but unmapped. Anthropic called Fable 5 "Mythos-class, made safe for general use." What else sits in that tier, and when it reaches the CLI, is unexplained .

The suspension is murkier still. On June 12, Anthropic said a US government export-control directive forced it to disable both models for all customers, leaving other models unaffected . The directive's specific concern was not shared with Anthropic or published; Anthropic disputed the apparent jailbreak rationale and said the detailed reasoning was withheld . No reinstatement timeline exists.

The CLI plumbing built around the model still ships: v2.1.176 made auto mode fall back to the best available Opus when Fable 5 is unavailable, so the orchestration path degrades gracefully rather than breaking . But the model behind it is dark.

So the practical takeaway splits cleanly. The orchestration depth, the v2.1.181 chain guard, parameter-scoped permission rules, enforceAvailableModels, and inline /config mutation are stable, documented, and usable today . Fable 5 access is not, and until Anthropic publishes either specs or reinstatement conditions, treat it as unavailable infrastructure, not a feature you can build against. Adopt the governance and orchestration controls now; hold the model in the "watch" column.

Frequently asked questions

What is Fable 5 and why was it suspended from Claude Code?

Fable 5 is Anthropic's "Mythos-class" model, made safe for general use and added to Claude Code in v2.1.170 on June 9, 2026 at $10 per million input tokens and $50 per million output tokens . On June 12, 2026, Anthropic stated that access to Fable 5 and Mythos 5 was suspended, citing a US government export-control directive that forced it to disable both models for all customers . The detailed concern was not disclosed, and other Anthropic models stayed available.

How does the v2.1.181 chain guard interact with the 5-level nesting cap from v2.1.172?

v2.1.172 (June 10) let sub-agents spawn sub-agents up to five levels deep, but that depth was a nominal limit . v2.1.181 (June 17) added a runtime guard against unbounded nested subagent chains, providing the practical enforcement of that five-level ceiling . In short, v2.1.172 introduced the capability and v2.1.181 enforced it at the call level, so recursive spawning is now actively prevented rather than only documented.

What does Tool(param:value) permission syntax enable that wasn't possible before?

Introduced in v2.1.178 (June 15), Tool(param:value) matching lets admins scope permission rules to specific parameter values inside a tool class, with * wildcards supported . For example, Agent(model:opus) permits Opus while blocking other models. Previously a rule allowed or denied an entire tool class with no parameter granularity, so this is the first way to constrain which arguments a tool may be called with.

Does /config key=value persist after the session ends?

No. /config key=value is per-session only. Added in v2.1.181 (June 17), it sets any setting inline from interactive mode, -p, or Remote Control, for example /config thinking=false . The override applies only to the current session. For permanent changes, edit settings.json or use project-level config files as before.

Is it safe to write to network drives or cloud-synced folders after upgrading to v2.1.181?

Yes. v2.1.181 (June 17) fixes the 0-byte and truncated Write/Edit output bug on network drives and cloud-synced folders . On any earlier version in this window (v2.1.170 through v2.1.179), upgrade before writing to mounted volumes, since the truncation could silently corrupt files written to those locations.