Claude Code v2.1.178: Precise Tool Permissions, Smarter Config Resolution, and Safer Sub-Agents
Claude Code's latest release adds parameter-level permission syntax, proximity-based .claude/ directory resolution, and pre-launch safety screening for sub-agents.
Update, 21 June 2026: Claude Code adds /config prompt-time commands, macOS Apple Events sandbox opt-in, and faster startup
A second update, reaching v2.1.181 (GitHub releases), builds on the permissions and sub-agent work covered in the original post with new convenience features and a round of stability fixes.
The headline addition is /config key=value syntax, which lets you set any configuration option directly from the prompt without touching a config file. It works in interactive sessions, -p mode, and Remote Control, making it particularly useful for CI pipelines that need per-run overrides.
macOS users running sandboxed workflows that rely on AppleScript or browser-based auth flows should note the new sandbox.allowAppleEvents opt-in setting. Without it, open, osascript, and similar tools were failing with error -600 in sandboxed sessions.
A startup regression introduced in v2.1.169 is also resolved. The first prompt no longer waits on a managed-settings fetch when no MCP servers are configured, recovering roughly 120 ms per launch in clean environments.
Additional fixes address prompt-cache reads broken on custom ANTHROPIC_BASE_URL and Foundry deployments, file corruption on network drives and cloud-sync folders, and a Remote Control bug where connecting from web or mobile silently switched the session model. The subagent panel from the previous release is refined: idle agents hide after 30 seconds and the list caps at five rows.
There are no breaking changes in this range, though opening URLs in fullscreen mode now requires Cmd+click on macOS by design.
Update, 21 June 2026: Claude Code broad release: agent-team tools streamlined, permissions tightened, auto mode review added
A substantial Claude Code release on June 21 builds on and partially supersedes the features covered below. The most significant structural change: TeamCreate and TeamDelete are gone. With CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 set, every session now has one implicit team and you spawn teammates directly via Agent(name:…). The team_name parameter still parses without error but is ignored, so existing configs need no immediate changes. The removal also closes a known security gap where subagents could create team shells they had no way to populate (GitHub issue #32723).
The pre-launch sub-agent safety screening introduced in the previous release has been extended: in auto mode, subagent spawns are now evaluated by the classifier before launch rather than only at the task boundary. The classifier runs a fast single-token pass first and only triggers chain-of-thought reasoning if that pass flags the transcript. Note that the default allow list includes pip install -r requirements.txt, so auto mode does not protect against supply chain attacks through unpinned dependencies.
The Tool(param:value) permission syntax covered below is now in active use alongside this update; Agent(model:opus) is the cited example for blocking high-cost subagent model calls. Nested .claude/skills directories also now load correctly, with name clashes resolved as <dir>:<name>. Full details are in the official changelog.
Update, 19 June 2026: Claude Code Auto Mode: Deprecation Warnings Now Cover Frontmatter-Specified Models in Sub-Agents
Claude Code v2.1.183 (changelog) extends the sub-agent safety work introduced in v2.1.178 by closing a visibility gap for automated pipelines. Model deprecation warnings now appear universally: written to stderr in -p print mode, and triggered by model names set in agent frontmatter, the Agent tool’s model parameter, /agents model picker selections, and the CLAUDE_CODE_SUBAGENT_MODEL environment variable.
Previously, deprecation notices only surfaced in interactive sessions. Teams running headless CI/CD jobs with hardcoded model names had no early signal before an API failure. Now, if a requested model has a scheduled retirement date or is being remapped to a newer version, the warning names the specific model so operators can update configs in advance.
Fallback behavior is non-breaking: a deprecated or blocked subagent model falls back to the inherited or default model rather than failing the request, but the warning still fires so the issue is visible.
This release also tightens auto mode guardrails. Destructive git commands including git reset --hard, git clean -fd, and git commit --amend are now blocked without explicit user intent, as are terraform destroy, pulumi destroy, and cdk destroy unless the specific stack was named in the request (GitHub releases).
The v2.1.178 coverage of sub-agent safety remains accurate; v2.1.183 adds deprecation visibility and expands the scope of blocked destructive operations.
Update, 17 June 2026: Claude Code fixes untrusted project settings OTEL certificate path injection and plugin PID lock accumulation
The release following v2.1.178 closes two bugs with direct relevance to enterprise deployments covered in the original post.
The more significant fix addresses a security gap in the trust model described here previously. A malicious repository’s .claude/settings file could set OTEL client-certificate paths without trust confirmation, potentially redirecting mTLS traffic in observability pipelines toward attacker-controlled infrastructure. The fix enforces trust confirmation before any untrusted project setting can configure certificate paths. Teams cloning external repositories or running Claude Code against shared codebases should treat this as a prompt-update scenario. See the official changelog for details.
The second fix is operational. Plugin .in_use PID lock files were accumulating without bound when sessions crashed or were killed hard. A daily sweep now purges orphaned markers automatically. No manual cleanup is needed after upgrading; the sweep handles existing backlog.
The same release also reduces CPU usage during streaming and spinner animations, restores a default five-minute idle timeout on Vertex and Foundry to abort stalled streams, and improves TaskCreate reliability with automatic repair of malformed inputs. Remote-managed settings with invalid entries now apply their remaining valid policies rather than silently dropping the entire payload.
Neither security fix nor lock file fix requires new configuration. Both take effect on upgrade.
Update, 16 June 2026: Claude Code v2.1.178+ adds Tool(param:value) permission syntax, nested .claude/ directory support, and safer auto mode
The original post covered the headline features accurately. This update adds detail on how each change works in practice, based on the official Anthropic GitHub changelog.
The most significant new capability is Tool(param:value) permission syntax, which lets you match rules against specific parameter values rather than entire tool classes. For example, Agent(model:opus) blocks Opus subagents while leaving other Agent calls unrestricted. Wildcard support is included.
The nested .claude/ directory behaviour is now confirmed: the skill, workflow, or output-style closest to the working directory takes precedence over a top-level default. Name clashes produce a qualified <dir>:<name> format rather than a silent override, which is particularly useful in monorepos.
The auto mode safety improvement is more significant than the original post indicated. Previously, the classifier only evaluated tool calls inside a running subagent; the spawn itself was unscreened. Now the classifier evaluates the delegated task description before the subagent launches, closing a meaningful gap for autonomous pipelines.
The release also bundles over a dozen bug fixes, including a regression where custom API gateways could receive a user’s Anthropic OAuth token instead of the gateway’s own credential, and a fix for MCP servers with paginated tools/list responses silently dropping tools beyond the first page.
Run claude --version to confirm your installed version.
Claude Code v2.1.178 is a focused release that tackles three things teams running Claude Code at any serious scale will care about: how precisely you can control what tools are allowed to do, how configuration behaves in complex project structures, and whether sub-agents are being properly screened before they run. Here’s what changed and why it matters.
Fine-Grained Tool Permissions with Tool(param:value) Syntax
Until now, Claude Code’s permission rules worked at the tool level. You could allow or block a tool entirely, but you couldn’t say “this tool is fine, except when it’s called with this parameter.” Version 2.1.178 changes that with a new Tool(param:value) syntax.
The practical upshot: you can now write rules like Agent(model:opus) in your deny list to prevent any sub-agent from spinning up with the Opus model. Wildcard support is included, so you have real flexibility for broader pattern matching too.
This fits into Claude Code’s existing permission structure. Rules sit in the deny, ask, or allow arrays in settings.json or managed-settings.json, and are evaluated in order, deny first. The first match wins, full stop.
For team and enterprise admins, this is a meaningful upgrade. Previously, the choice was binary: allow the Agent tool or block it entirely. Now you can allow sub-agents in general while restricting which models they can invoke, which is useful for cost governance, latency control, or simply enforcing which models have been approved for your environment. It’s policy-level control without needing a custom wrapper.
One detail worth noting: if a managed configuration contains an entry that fails schema validation, Claude Code now strips just that entry, logs a warning, and enforces everything else. A single typo in a policy file no longer silently disables your entire ruleset.
Proximity-Based .claude/ Directory Resolution
If you work in a monorepo or a project with nested sub-projects, you’ve probably hit the point where a single root-level .claude/ directory becomes unwieldy. This release formalises how Claude Code handles conflicts when multiple .claude/ directories exist at different levels of your file tree.
The rule is straightforward: the closest .claude/ directory to where you’re working wins. This applies to agents, workflows, and output styles. If you’re editing a file three levels deep and there’s a .claude/ directory two levels up and another at the root, the nearer one takes precedence for name collisions.
Skills get slightly different treatment. When Claude Code loads skills from a nested .claude/skills directory, any name that clashes with a parent-level skill gets qualified as <dir>:<name>. Both remain available; you just need the qualified name to reach the parent version. This avoids the old problem where a nested skill would silently shadow a root-level one.
Project-scope workflow saves also now target the closest existing .claude/workflows/ directory rather than defaulting to root. If you’ve set up a workflow for a specific sub-project, saving changes to it won’t accidentally write to the wrong place.
For monorepo developers, this removes a category of subtle configuration bugs that were hard to debug because the wrong skill or workflow would load without any obvious indication of why.
Auto Mode Now Pre-Screens Sub-Agent Spawns
Auto mode in Claude Code works by routing tool calls through a safety classifier before execution. The classifier checks whether an action matches what was requested, looks for destructive patterns (mass file deletions, data exfiltration attempts, malicious code execution), and blocks anything that looks like it’s been driven by hostile content Claude read along the way. That last part is a prompt-injection defence.
There was a gap, though. Sub-agent spawns, the moments when Claude Code creates a new agent to handle part of a task, were not being pre-screened by the classifier before launch. That meant a sub-agent could be spawned and then immediately request a blocked action without the classifier having had a chance to evaluate the spawn itself.
Version 2.1.178 closes that gap. Sub-agent spawns are now evaluated by the classifier before the agent launches. If the spawn looks problematic, it gets blocked before anything runs.
This matters most if you’re using auto mode for complex, multi-step tasks where Claude Code is delegating work to sub-agents autonomously. The safety model is now consistent across the whole execution chain, not just the top-level tool calls.
Worth being transparent about the trade-off: the classifier adds a small overhead to each tool call, which can marginally increase token consumption and latency. For most workflows that’s negligible, but it’s worth knowing if you’re running high-volume automated pipelines.
Also fixed in this release: the classifier was incorrectly blocking some actions with a “could not evaluate this action” error when it ran out of output tokens mid-reasoning. That edge case is resolved.
Other Fixes Worth Knowing About
A few other changes in this release that affect day-to-day use:
Background session environment isolation. Background sessions were inheriting ANTHROPIC_* environment variables (gateway URL, custom headers, model aliases) from the shell that started the background daemon. If your team uses a custom API gateway, this could cause authentication failures or unexpected model routing. That’s fixed.
Auth fix for custom gateways. Related: claude agents workers were failing with 401 Invalid bearer token when the daemon was started from a shell using ANTHROPIC_BASE_URL and ANTHROPIC_AUTH_TOKEN. That’s resolved.
Sub-agent transcript visibility. Viewing a sub-agent’s transcript now shows tool results and live progress, which makes it much easier to understand what a sub-agent actually did. Messages sent while a sub-agent was finishing its turn were also being dropped, and that’s fixed. Backgrounding a running sub-agent with Ctrl+B no longer restarts it from scratch.
VSCode integration. Auto mode no longer requires the bypass-permissions setting to appear in the mode picker. There’s also a dismissable first-run notice that explains auto mode when it’s first active, which helps new users understand what they’ve turned on.
The Bigger Picture
This release is incremental in scope but deliberate in direction. The Tool(param:value) syntax and the sub-agent pre-screening both point toward the same goal: making it practical to run Claude Code with meaningful automation while keeping actual control over what it does. The .claude/ proximity resolution is a quality-of-life fix that will matter a lot to teams who’ve tried to manage complex project configurations and hit confusing edge cases.
If you’re running Claude Code in a team context, the permission syntax update in particular is worth testing against your existing settings.json configuration. The ability to restrict by parameter rather than by tool name opens up policy patterns that weren’t possible before, and for environments with cost or compliance constraints around specific models, Agent(model:opus) style rules are going to be immediately useful.