Claude Code release notes: 2.1.178 adds agent rules by tool and model
Part of the series: Claude Code release notes

Claude Code 2.1.178 is not the kind of release that sounds huge in a headline. That is why it is worth noticing. Anthropic added permission rules that can match tool input parameters, for example Tool(param:value) and Agent(model:opus). For teams starting to run more subagents, the control question gets more practical: not only "may the agent use this tool?", but "may the agent use it in this way?"
Source: Claude Code changelog and GitHub release v2.1.178
Claude Code release notes: 2.1.178 is about more precise agent rules
A coding agent is an AI assistant that can read a project, edit files and drive parts of a development workflow. A permission rule decides which tools or actions that agent may use. In 2.1.178, the rule can look at parameters, not only the tool name.
The clearest example in the release notes is Agent(model:opus), which can be used to block Opus subagents. That is a small syntax change with everyday value: expensive, powerful or sensitive agent runs can be separated from simpler tasks without turning the whole agent workflow off.
Source: GitHub release v2.1.178
Nested skills make project rules more local
The release notes also say that skills in nested .claude/skills folders now load when you work on files there. If two skills share a name, the nested skill appears as <dir>:<name>, so both can stay available. Claude Code also chooses the closest definition for agents, workflows and output styles when names collide.
That fits teams where different parts of the same repo need different rules. A client project may need stricter review. An internal prototype may use a faster workflow. The point is not to turn every folder into a tiny bureaucracy. It is to keep instructions and tools closer to the work they govern.
Source: Claude Code changelog and Claude Code settings
What Nordic teams can test this week
Start with one agent workflow where the boundary is already obvious: code review, migration, documentation, or debugging. Write down which model is reasonable, which tools the agent needs, which files it may touch, and where a human should approve the next step.
For Hammer customers, this sits inside Tool Forge: env vars and secret managers for keys, scoped permissions for tools, edit-before-publish habits, approval gates for costly or risky steps and a simple audit log after the run. That makes Claude more useful, not less.
Try this prompt this week
Human step: First check that the team’s Claude Code installation is actually running 2.1.178 or later with claude --version, and choose a repo where you already have .claude settings to review.
Source: Claude Code changelog and npm registry for @anthropic-ai/claude-code
Read the project’s .claude settings, agents, workflows and skills.
Find one subagent workflow where model choice or tool input should be limited.
Propose a minimal permission rule and explain which risk it reduces.
Point to the files or folders where the rule belongs.
End with what a human should review before the change is enabled.
Good output should:
- point to a real agent, workflow or skill in the project
- separate model cost, access and human approval
- suggest a small rule instead of shutting the whole workflow down
- leave a short review note the team can understand later
The short version
Claude Code 2.1.178 makes agent work a little easier to govern. Not through another big model announcement, but through rules that can sit closer to the tool, folder, and workflow. That is often where AI starts to become real inside a team: the right agent gets the right freedom, and the rest waits for a human.
FAQ
What matters most in Claude Code 2.1.178?
The most practical change is permission rules that can match tool parameters, such as Agent(model:opus), so teams can govern subagents more precisely.
Does every team need to change its Claude Code rules now?
No. Start with one agent workflow where model choice, file access or tool input already needs human control. Add a small rule only if it reduces a real risk.
Why do nested .claude/skills folders matter?
They let instructions and skills follow the part of the project where the work happens, instead of forcing the whole repository to use the same agent rules.
The Forge newsletter
Get new articles in your inbox
Pick the topics you care about. No noise, at most one email a week.
We follow GDPR. Unsubscribe anytime.


