Claude Code
Sourced signals for Claude Code: release changes, governance moves, runtime shifts, and operator consequences. Each links to the run that produced it. The Claude Code profile carries the current evergreen state.
August 2026
-
Shell commands could hide part of themselves from the approval prompt, in the fortnight the prompt stopped being the default
- Upgrade past 2.1.224, then re-read your own sandbox deny rules for trailing slashes. That defect invalidated configuration an operator wrote and believed in, and nothing surfaced the failure.
- Approval logs from before this window are evidence of what was asked, not of what ran. If you retain transcripts for audit, the recorded approval and the executed command can differ, and no artifact you hold identifies which sessions were affected.
- Enumerate custom agent definitions: a separate fix closed an agent definition whose bypass mode ignored an organisation policy that had disabled it.
Run: 2026-08-10-weekly-digest-2026-08-03_2026-08-10-frontier-v0
July 2026
-
Claude Code permission rules did not refuse what they described, and the fix missed the channel most people run
- Move to the latest channel or pin minimumVersion to 2.1.214, then re-test any rule you rely on by writing a deny and confirming the action is actually refused. An operator who wrote Edit(src/**) believed they had scoped write access to one directory and did not have it.
Run: 2026-07-27-weekly-digest-2026-07-02_2026-07-27-frontier-v0
-
Claude Code background agents now commit, push, and open draft PRs instead of stopping to ask
- Claude Code v2.1.198 makes subagents background by default and says background agents launched from `claude agents` now commit, push, and open a draft PR after worktree code work instead of stopping to ask.
- Before upgrading shared repos, decide whether background agents may write commits and branches, wire Notification hooks, and rely on branch protection rather than a human sitting at the terminal.
Run: 2026-07-02-weekly-digest-2026-07-01_2026-07-02-frontier-v0
-
Claude Code 2.1.196 closes an MCP self-approval hole and binds Remote Control to the Anthropic host
- 2.1.196 is a security release: `claude mcp list`/`get` no longer spawn `.mcp.json` servers that a repo self-approves -- closing a path where merely inspecting MCP config in an untrusted repo could launch a repo-declared server. And Remote Control is now disabled when `ANTHROPIC_BASE_URL` points at a non-Anthropic host (org-configurable), so a redirected base URL cannot silently drive remote control.
- Upgrade to 2.1.196+ and re-audit MCP trust in any workflow that opens untrusted repositories; if you proxy `ANTHROPIC_BASE_URL`, confirm the new Remote Control binding matches your intent.
Run: 2026-07-01-weekly-digest-2026-06-24_2026-07-01-frontier-v0
-
Sonnet 5 propagated across harnesses in one week: Claude Code makes it the default (1M context); Pi adds support
- Claude Code v2.1.197 (2026-06-30) makes Claude Sonnet 5 the default model, with native 1M-token context. Pi v0.80.3 (2026-06-30) added Sonnet 5 support (Anthropic-compatible + Bedrock) the same week. A new frontier model became a default and a cross-harness option within days.
- Know your default changed: if you pin models for cost/behavior reasons, confirm whether you are now on Sonnet 5 with a 1M window (and the cost/latency that implies), or set the model explicitly.
Run: 2026-07-01-weekly-digest-2026-06-24_2026-07-01-frontier-v0
June 2026
-
The five-level subagent depth cap did not bind for foreground spawns until 2.1.181
- 2.1.181 fixed foreground subagents spawning unbounded nested chains; they now respect the same 5-level depth limit as background subagents. An operator who relied on last window's depth cap (2.1.178) for foreground delegation was, in the interim, not protected by it.
- Upgrade past 2.1.181 and re-test that a foreground delegation tree actually stops at five levels rather than assuming the announced cap binds.
Run: 2026-06-23-weekly-digest-2026-06-16_2026-06-23-frontier-v0
-
Agent(type) deny and Agent(x,y) allowed-types rules were not enforced for named subagent spawns until 2.1.186
- 2.1.186 fixed `Agent(type)` deny rules and `Agent(x,y)` allowed-types restrictions not being enforced for named subagent spawns. An operator who wrote those rules when the argument-aware grammar was announced was unprotected by them until this fix.
- Upgrade past 2.1.186, then write an `Agent(type)` deny for a subagent you expect blocked and confirm a named spawn is actually refused, not silently allowed.
Run: 2026-06-23-weekly-digest-2026-06-16_2026-06-23-frontier-v0
-
Auto mode now blocks specific destructive git/IaC commands and reclassifies scheduled-task and webhook triggers
- 2.1.183 enumerated destructive commands the auto-mode classifier now blocks — `git reset --hard`, `git checkout -- .`, `git clean -fd`, `git stash drop` (when you did not ask to discard work), `git commit --amend` for commits the agent did not make this session, and `terraform`/`pulumi`/`cdk destroy` unless you asked for the specific stack.
- 2.1.183 also fixed scheduled-task and webhook trigger deliveries being treated as keyboard input; they now classify as task notifications and can no longer approve a pending action or set the session title under auto mode.
- Operators running auto mode should upgrade past 2.1.183; the blocks are conditional (gated on what you asked for), not unconditional refusals.
Run: 2026-06-23-weekly-digest-2026-06-16_2026-06-23-frontier-v0
-
Subagents can spawn subagents five deep, and auto mode now classifies spawns before launch
- 2.1.172 lets a subagent spawn its own subagents up to 5 levels deep (new capability and a new governance surface); 2.1.178 then made the auto-mode classifier evaluate a spawn before launch, closing a gap where a deeply nested agent could request an action the operator's policy would block at the top.
- Operators running under auto mode should upgrade past 2.1.178 before trusting a delegation tree, and use argument-aware permission rules to cap what spawned agents can do.
Run: 2026-06-16-weekly-digest-2026-06-04_2026-06-16-frontier-v0
-
Permission rules can finally match a tool's arguments (Agent(model:opus))
- 2.1.178 added Tool(param:value) syntax so a rule can match input parameters, e.g. Agent(model:opus) blocks Opus subagents; permissions move from all-or-nothing per tool to per-argument.
- Operators governing delegated trees should reach for this to cap model tiers and arguments inside subagents.
Run: 2026-06-16-weekly-digest-2026-06-04_2026-06-16-frontier-v0
-
Org model allowlists are finally binding, even against the default model
- enforceAvailableModels (2.1.175) makes the availableModels allowlist constrain the Default model and blocks user/project widening; a cluster of fixes closed env-var, /fast, subagent, advisor, and dispatch escape hatches. This is the lever an enterprise needs to decide whether Fable 5 is reachable per-org.
Run: 2026-06-16-weekly-digest-2026-06-04_2026-06-16-frontier-v0
-
Untrusted-repo OTEL cert injection and pre-warmed-worker trust bleed closed
- 2.1.169 fixes untrusted project settings setting OTEL client-certificate paths without a trust prompt (credential-path injection from a hostile repo); 2.1.172/2.1.174 fix pre-warmed background workers reading another directory's .mcp.json approvals/trust and inheriting another session's ANTHROPIC_* provider env. Upgrade past 2.1.174 and re-audit background-agent and untrusted-repo workflows.
Run: 2026-06-16-weekly-digest-2026-06-04_2026-06-16-frontier-v0
-
Anthropic's Fable 5 launches and is adopted across rival harnesses within days
- Claude Code 2.1.170 shipped access to Claude Fable 5, a 'Mythos-class' model; OpenClaw and Pi added Fable 5 support within days (Pi with xhigh effort). A frontier model now reaches the long tail of agent harnesses in a week; the governance lever is the model-allowlist work (separate signal).
Run: 2026-06-16-weekly-digest-2026-06-04_2026-06-16-frontier-v0
-
Relayed SendMessage from peer sessions no longer carries user authority
- 2.1.166: messages relayed via SendMessage from other Claude sessions no longer carry user authority; receivers refuse relayed permission requests and auto mode blocks them. Closes a confused-deputy path in multi-session orchestration.
Run: 2026-06-16-weekly-digest-2026-06-04_2026-06-16-frontier-v0
-
Permission and deny rules now enforced as written across WebFetch, Windows paths, and Glob/Grep
- Three distinct gaps where a configured permission/deny rule silently failed to apply are closed in the 2.1.160-2.1.162 line: custom WebFetch rules now override built-in preapproved domains, Windows rules with backslashes or case-variant paths now match, and Read deny rules now hide files from Glob and Grep results.
- Operators who wrote allow/deny policy and assumed it was enforced were running with a false sense of coverage; the fix is gated purely on upgrading past these versions, so the operator action is 'upgrade, then re-audit whether any policy was silently bypassed in the prior window.'
- The Read-deny-vs-Glob/Grep gap is the sharpest: a file an operator denied for Read was still discoverable (and its path/contents surfaceable) via search tools, defeating the access-control intent.
Run: 2026-06-03-weekly-digest-2026-05-28_2026-06-03-frontier-v0
-
Agent view exposes why a session is blocked and fan-out progress for scripted supervision
- claude agents --json now includes a waitingFor field naming what a blocked session is waiting on (e.g. a permission prompt), and claude agents rows now show done/total progress before detail when work is fanned out.
- Operators scripting or monitoring agent fleets can now programmatically distinguish 'stuck on a permission prompt' from other waits and read parallel-task completion, which is the difference between a watchdog that can unblock a session and one that can only detect silence.
- The operator action is to wire waitingFor and the progress counter into supervision tooling so stuck-agent triage stops requiring a human to open each session.
Run: 2026-06-03-weekly-digest-2026-05-28_2026-06-03-frontier-v0
-
Writes to execution-granting config and shell startup files now prompt even in acceptEdits mode
- Two new guardrails land together: acceptEdits mode now prompts before writing build-tool config that grants code execution (.npmrc, .yarnrc*, bunfig.toml, .bazelrc, .pre-commit-config.yaml, .devcontainer/, etc.), and the agent now prompts before writing shell startup files (.zshenv, .zlogin, .bash_login) and ~/.config/git/.
- Operators who ran acceptEdits or auto-leaning modes previously had a silent write path into files that execute code on the next shell, install, or commit; the new prompt converts that into a confirmation checkpoint.
- The operator action is to recognize that these prompts will now fire and not blanket-allow them — the prompt is the supply-chain/persistence defense, so auto-approving it re-opens the vector.
Run: 2026-06-03-weekly-digest-2026-05-28_2026-06-03-frontier-v0
May 2026
-
Auto Mode now available on Bedrock, Vertex, and Foundry for Opus 4.7 / 4.8
- Auto Mode's permission-handling posture, previously tied to first-party Anthropic auth, now extends to the cloud provider APIs (AWS Bedrock, Google Vertex, Foundry) for Opus 4.7 and 4.8, opt-in via CLAUDE_CODE_ENABLE_AUTO_MODE=1.
- The operator decision is governance-shaped: teams running Claude Code through a cloud-provider procurement path can now deploy the reduced-prompt autonomy posture they could not before, which changes what consent ceremony exists on those deployments.
- Because Auto Mode shifts permission decisioning away from per-action prompts, an operator enabling it on a Bedrock/Vertex deployment must confirm their managed-settings deny rules carry the governance weight the prompts used to.
Run: 2026-06-03-weekly-digest-2026-05-28_2026-06-03-frontier-v0
-
Auto mode becomes the default permission posture
- Operators with managed Claude Code deployments must re-audit what Auto mode classifies as safe by default — the consent gate is gone.
- Admins relying on the opt-in consent dialog as a visible posture check have lost that surface; equivalent visibility now comes from managed-settings policy, not from a runtime prompt.
- Skill authors should evaluate `disallowed-tools` for skills that should run with a reduced tool surface.
- Hook authors should consider whether `MessageDisplay` is a governance gain or a censorship hazard for their deployment.
Run: 2026-05-27-weekly-digest-2026-05-13_2026-05-27-frontier-v0
-
Three de-facto security advisories without a separate advisory surface
- Windows operators on 2.1.148 or earlier with PowerShell allowlists, git worktree workflows, or enterprise login pinning should upgrade to 2.1.149+ before deploying new agents.
- Operators monitoring for security-advisory-shape events (RSS, CVE feeds) need to recognize that Anthropic ships these as ordinary changelog entries; the changelog is the de-facto advisory surface.
- Source-contract owners should decide whether to amend `sources/claude-code.yml` to add an explicit security advisory surface or to document the changelog as carrying that role.
Run: 2026-05-27-weekly-digest-2026-05-13_2026-05-27-frontier-v0
-
Agent view, goal completion, and governance hardening
- `claude agents` is the new canonical surface for multi-session supervision; operators running parallel Claude Code sessions should evaluate it now as their primary management interface.
- /goal changes how long-running autonomous work is structured; operators should test goal-based termination against their most common multi-turn workflows.
- `continueOnBlock` enables advisory governance hooks; existing PostToolUse blocks should be redesigned to pass rejection reasons so Claude can adapt rather than just stop.
- `x-claude-code-agent-id` / `x-claude-code-parent-agent-id` headers and OTel span attributes enable call-tree attribution; logging pipelines receiving Anthropic API calls should start capturing these to distinguish parent sessions from subagents.
- API key auth now disables Remote Control, /schedule, and claude.ai MCP connectors; operators using API key should audit reliance on these surfaces before upgrading.
Run: 2026-05-12-partial-cycle-claude-code-2026-05-07_2026-05-12-frontier-v0
-
Worker-native state is becoming a memory layer.
- Recaps, memory patches, skill curators, and task state are moving into worker tools. Operators should use them, but should preserve an operator-owned record of what state governed each run.
-
Authority semantics are explicit but fragmented.
- Permission profiles, workspace trust, env loading, hooks, MCP behavior, extension schemas, and provider transports differ by worker and release.
-
Verification is becoming a worker capability.
- Provider-native review, multi-agent execution, subagent evals, curator reports, and QA-like cloud fleets can catch useful issues, but their verdicts are not automatically the operator's truth.
-
Plugin, extension, and skill ecosystems are becoming the integration surface.
- The practical power of worker CLIs increasingly depends on plugins, hooks, extensions, skills, and transport modules, not just the base model.
-
Provider-native long-horizon state is now table stakes.