Claude Code 2.1.178 Tightens Subagent Permissions Where Auto Mode Used to Trust Too Much
Claude Code 2.1.178 shipped a changelog long enough to bury the lede, which is this: permission systems for coding agents have to reason about parameters, models, MCP servers, and nested project scopes — not just tool names. Once agents can spawn agents, auto mode is no longer "trust the model" with nicer branding. It is a policy engine that needs to understand delegation.
The new Tool(param:value) permission syntax is the headline for teams treating Claude Code as team infrastructure. The example Anthropic gives is Agent(model:opus) — blocking Opus subagents while allowing other model sizes. That is intent-level permissioning. Blocking the entire Agent tool is blunt. Allowing all subagents is risky. Matching specific model parameters lets teams say "subagents are fine, expensive ones need review." In the current Claude Code environment, where subagents, skills, workflows, nested project configs, MCP servers, and background sessions all interact, the permission boundary needs to understand more than just tool names.
The auto mode classifier change is the more important security fix, and the release note is short enough to miss. Auto mode now evaluates subagent spawns with the classifier before launch, explicitly closing a gap where a subagent could request a blocked action without review. The implication is large: every agent framework needs to apply policy at delegation boundaries, not only at direct tool calls. A parent agent asking a child agent to do work is still a user-visible action with cost, permissions, and data-access consequences. If a subagent can escalate without the classifier seeing the request, auto mode becomes an escalation path rather than a convenience feature.
The MCP disallowedTools fix belongs in the same story. The release corrects a long-standing behavior where MCP server-level specs — mcp__server, mcp__server__*, and mcp__* in subagent denies — were silently ignored. If a team believed a subagent lacked MCP access while the runtime behaved otherwise, that is not a missing feature. It is a false security boundary. Silent policy failure is worse than a missing feature because it produces false confidence. For teams running MCP servers against internal systems, the test is direct: create a subagent, add server-level MCP specs to its deny list, and verify denial works before trusting the configuration.
Nested .claude resolution is more than convenience for monorepo teams. A frontend package, infra directory, and security-sensitive service may have different skills, workflows, output styles, and agents. "Closest config wins" is the right mental model for local policy, but it creates shadowing risk. Anthropic's name clash naming — <dir>:<name> — makes ambiguity visible instead of silently picking one skill. Teams should still document which directories own which agent configs, because invisible local overrides are how policy becomes folklore and unexpected behavior becomes someone's production incident.
The release also fixes background subagent transcript and progress handling, stale auth caches, Chrome OAuth account mismatches, custom API gateway bearer-token failures for claude agents workers, and background sessions stuck in "Working" state. Compaction now honors --fallback-model, falling back through the configured chain on overload or model-availability errors. These are the kind of fixes that matter in long-running team sessions where Claude Code stays open all day across branch switching, credential rotation, and multi-developer git operations.
The practitioner checklist for 2.1.178 should go beyond "it updated." After upgrading, add at least one Tool(param:value) rule for subagent model selection and verify enforcement. Confirm auto mode classifies subagent launch requests before they reach the scheduler. Test MCP server-level denies inside subagents — not just tool-level denies. Run a nested .claude scenario in a monorepo and confirm clash naming makes ambiguous configs visible. If you use fallback models, simulate an overload and confirm compaction follows the configured fallback chain.
There is a deeper evaluation worth doing on any Claude Code upgrade: how does the permission model behave when two subagents are running concurrently, each trying to spawn their own children? The Tool(param:value) syntax adds a new dimension to that question. If Agent(model:opus) is blocked, does a subagent that wraps an Opus call through a tool intermediary still get caught? Does the classifier see the parameter before or after the model is selected? These are the edge cases that determine whether policy is enforced at the right layer, and they are only answerable by testing against real workflows, not by reading release notes.
The auth and session fixes deserve their own runbook. Stale cached request config after credential refresh, Chrome OAuth account mismatches, custom API gateway bearer-token failures, and background sessions stuck in "Working" are the kind of bugs that feel intermittent until you realize they affect every session that hits the specific edge. After upgrading, rotate a credential and confirm the agent picks it up without a restart. Open two sessions with different Google accounts and confirm OAuth flows stay segregated. Point a claude agents worker at a custom gateway and confirm bearer tokens flow correctly. These are not exotic setups — they are exactly what engineering teams run in production.
The compaction fallback behavior deserves specific attention from teams running Claude Code at scale. If your primary model hits overload or availability errors, compaction kicks in. The question is whether compaction attempts the right fallback sequence — not just the first available model, but the configured chain. A team that set --fallback-model expecting a specific cascade and got an unexpected default instead has a silent policy violation that only surfaces as a billing surprise or a quality dip. Test it explicitly.
The agent control plane is now deep enough that "it asked before running bash" is an inadequate security review. Teams running Claude Code for more than personal use should be building permission test suites, not just reading release notes. The agent that wins is not the one that asks the fewest questions. It is the one whose permission model maps accurately to what humans actually intended.
Sources: Anthropic Claude Code GitHub Release, Claude Code Changelog