Claude Code 2.1.178 Tightens Subagent Permissions Where Auto Mode Used to Trust Too Much

Claude Code 2.1.178 reads like a bugfix release until you notice the pattern: permissions are moving closer to the place where delegation actually happens. That is the right direction, because once agents can spawn agents, “ask before running bash” is no longer a sufficient security model. The runtime has to reason about which child agent is being launched, which model it will use, which MCP servers it can touch, and which nested project policy applies.

Claude Code v2.1.178 introduces Tool(param:value) permission syntax, with wildcard matching and an example that says the quiet part out loud: Agent(model:opus). In plain English, teams can now write rules that distinguish “subagents are allowed” from “this expensive or sensitive subagent model should be blocked or reviewed.” That is a more useful policy surface than treating the entire Agent tool as one undifferentiated blob.

Parameter-aware permissions are overdue

Tool-level permissioning was always going to hit a ceiling. Blocking the whole Agent tool is too blunt for teams that actually use subagents. Allowing all subagents is too trusting for teams with cost controls, model-tier policies, or data-access boundaries. A parameter-aware syntax lets policy match intent more closely: not just “can this tool run?” but “can this tool run with these arguments?”

The Agent(model:opus) example is particularly useful because it ties permissioning to both cost and capability. High-end models may be better for hard reasoning, but they are also more expensive and may be inappropriate for routine background tasks. A team might allow cheaper subagents automatically, require review for Opus, and block particular model/tool combinations in sensitive repositories. That is not bureaucracy. That is the operational reality of coding agents inside organizations where budget, data access, and auditability are all first-class concerns.

The bigger lesson applies beyond Claude Code. Agent frameworks should not pretend all tool invocations are equal. Read(file:path), Bash(command:...), Agent(model:...), and mcp__server__tool(args:...) all carry different risk depending on parameters. A runtime that cannot express parameter-level policy eventually forces teams into bad choices: disable useful capability entirely, or trust too much because the policy language is weak.

Auto mode needed a delegation boundary

The release also says auto mode now evaluates subagent spawns with the classifier before launch, closing a gap where a subagent could request a blocked action without review. This is the line that should make teams re-read their assumptions about “auto.” Auto mode is not just convenience. It is policy execution with a friendly name.

If a parent agent can launch a child agent that requests a blocked action without the same review path, then the child boundary becomes an escalation path. The parent did not directly perform the blocked action; it delegated to something that could. For humans, that distinction is meaningless. For a permission engine, it is the difference between a secure control plane and a permission bypass with better UX.

Claude Code’s fix is important because policy has to follow delegation. A subagent launch consumes tokens, inherits or receives context, may touch tools, and may produce side effects. It should be classified before launch, not cleaned up afterward in logs. The more agent products add background workers, workflows, skills, MCP tools, and nested project config, the more important this becomes. Delegation is not a neutral internal implementation detail; it is an externally meaningful action.

Practitioners should test this directly after upgrading. Configure a rule that blocks or reviews a particular subagent model. Try to launch it under auto mode. Confirm the classifier path triggers before work starts. Then repeat the test through any workflow, skill, or helper command your team relies on. Security reviews that only test direct user prompts are missing the path agents actually use under load.

MCP denies that fail silently are worse than missing policy

The MCP-related fix belongs in the same trust-boundary story. Claude Code now handles MCP server-level specs such as mcp__server, mcp__server__*, and mcp__* in subagent disallowedTools instead of silently ignoring them. Silent policy failure is one of the most dangerous bugs in agent infrastructure because it creates false confidence. A team thinks a subagent cannot access an MCP server; the runtime behaves otherwise.

MCP servers are not toy plugins anymore. They are how agents reach databases, internal APIs, GitHub, documentation systems, deployment helpers, ticketing systems, and bespoke company tools. A server-level deny is often the cleanest way to say: this subagent should not touch that class of capability. If the deny syntax is accepted but ignored, the interface has lied to the operator.

The test is straightforward. Create a subagent, deny an MCP server at the server level, and attempt to call one of its tools. Then deny the wildcard form. Then test an allow path. If your agent platform does not make these outcomes obvious, do not put sensitive MCP servers behind it and assume policy will save you.

Nested project config is useful, and therefore risky

Claude Code 2.1.178 also improves nested .claude behavior. Nested .claude/skills directories now load based on the working file, with name clashes surfaced as <dir>:<name> so both remain available. Agents, workflows, and output styles resolve closest to the working directory, and project-scope workflow saves target the closest existing .claude/workflows/.

That is the right mental model for monorepos. A frontend app, infrastructure directory, and security-sensitive backend service may need different skills, workflows, and output styles. “Closest config wins” lets local teams encode local practice. It also creates shadowing risk. A workflow named the same thing in two directories is not just a convenience issue; it can change what the agent believes it should do while operating in a specific subtree.

Surfacing clashes as <dir>:<name> is useful because ambiguity becomes visible. Teams should still document ownership. If a repository has multiple nested .claude directories, the code owners should know which directories define policy, which define workflow shortcuts, and which are merely local helpers. Invisible local overrides are how team agent policy turns into folklore.

The rest of the release reinforces the maturity theme: background subagent transcript/progress handling is fixed, ctrl+b backgrounding no longer restarts a running subagent from scratch, compaction honors --fallback-model during overload or availability errors, and stale auth/session issues get cleaned up. These are not headline features, but they reduce the category’s worst failure mode: the user thinks the agent is following one state machine while the runtime is following another.

The upgrade advice is concrete. Add at least one Tool(param:value) rule for subagent model selection. Verify auto mode classifies subagent launches. Confirm MCP server-level denies work inside subagents. Test nested .claude resolution in a real monorepo. Simulate fallback-model compaction on overload. Claude Code’s control plane is now deep enough that a casual permission smoke test is not enough.

Claude Code 2.1.178 is policy catching up to delegation. That is exactly where the category has to go. Once agents can spawn agents, permission systems must understand parameters, models, MCP servers, and project scope. Otherwise auto mode is just trust-me mode with nicer branding.

Sources: Claude Code v2.1.178 release, Claude Code changelog, Claude Code docs index