Claude Code release notes: 2.1.214–2.1.215 makes review explicit

Claude Code 2.1.214 tightens permission checks for file paths, shell commands, remote sessions, and Docker connections. Version 2.1.215 then puts you in charge of the final checks: Claude no longer invokes /verify and /code-review on its own. You choose when they run.

For teams connecting a coding agent to real repositories and CI workflows, that boundary is useful. Claude Code stops more ambiguous commands, while verification becomes a visible part of the routine instead of something that may happen in the background.

Claude Code release notes 2.1.214: more commands stop at the gate

A permission rule defines which tools and actions an agent may use without asking. Version 2.1.214 fixes a bug where an allow rule such as Edit(src/**) could approve writes to nested src folders elsewhere in the directory tree. The rule is now limited to the intended folder under the working directory.

The same release makes several shell checks stricter. Commands longer than 10,000 characters always require approval. Certain file-descriptor redirects, zsh expressions, and help or man calls that could be misread now stop for review. Remote sessions should no longer proceed before the local confirmation dialog completes, and Docker or Podman commands with flags that can redirect the connection to another daemon require approval.

Source: Claude Code 2.1.214 on GitHub

The tighter checks make a real integration more predictable. Keep permissions scoped, store API keys in environment variables or a secret manager, and place an approval gate before writes or deployment.

The release also improves the run receipt. OpenTelemetry logs gain fields for message ID, client request, and tool source. OpenTelemetry is a standard for collecting traces, metrics, and logs from a system. The new fields make it easier to connect a tool run to the right message when a team needs to investigate what happened.

Source: Claude Code changelog and Claude Code permissions

Claude Code release notes 2.1.215: you start the verification

Version 2.1.215 has one line in its release note, but it changes the working rhythm. Claude no longer starts the /verify and /code-review skills itself. The user needs to invoke them when it is time to check the work.

That means review needs a defined place in the routine. Let the agent do the work, collect a short run receipt, then start verification and code review at a chosen point, such as before a pull request or merge. Nobody has to guess whether the check already ran.

Source: Claude Code 2.1.215 on GitHub

How teams can use both changes in one coding workflow

Start by reviewing the rules in /permissions. Claude Code evaluates deny, then ask, then allow. Claude Code enforces those rules outside the language model, so an instruction in the prompt cannot grant the agent more access.

When the agent works with CI, issue tracking, or other systems through MCP, give each connection scoped permission. MCP, the Model Context Protocol, is the standard that connects Claude to external tools and data sources. Keep the run log and review results with the change. This creates a concrete control point without slowing useful work.

This is a natural Tool Forge job: connect Claude to the right systems, give the integration clear permissions, and place explicit review where it is actually needed.

Try this prompt this week

Human step: Check the version and update Claude Code to 2.1.215 through your normal installation channel. Open the correct repository. When the agent's work is ready, invoke /verify and /code-review yourself; version 2.1.215 does not start them automatically.

Source: Claude Code 2.1.215 and Claude Code permissions

Read the current diff, CLAUDE.md, and the project's test configuration.
Map each changed behavior to an existing test or check.
Run only checks supported by the repository.
Report failures with file references and separate evidence from assumptions.
List unresolved risks and what a person needs to approve.
Do not edit files; return a compact review packet.

Good output should:

• Use the project's real checks instead of invented commands.
• Show which changes still lack verification.
• Leave a compact packet that can be compared with /verify and /code-review results.

Run the routine on the next bounded change. The new boundary in 2.1.215 then becomes concrete: the agent prepares the evidence, while the team owns the timing of review.