Claude Code
Every signal accepted for Claude Code. Each links to the run that produced it. The Claude Code profile carries the current evergreen state.
June 2026
-
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.
- Add worker-native state fields to adapter receipts: recap handles, memory patch ids, curator reports, skill reports, and resume state.
-
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.
- Bitter capability profiles should record worker-native permission and trust semantics instead of assuming a uniform authorization model.
-
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.
- Treat worker verification as evidence inputs. BitterQA or the run contract should still own the final evidence standard and settlement.
-
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.
- Adapter receipts should include enabled plugin/extension/skill surfaces and should distinguish worker-local skills from Bitter-owned memory.
-
Provider-native long-horizon state is now table stakes.