Claude Code 2.1.163 Turns Version Policy, Plugins, Hooks, and MCP Session Continuity Into Runtime Governance

Claude Code v2.1.163 is not trying to win a demo. It is trying to answer the question every platform team eventually asks about coding agents: who is allowed to run what version, with which plugins, under which hooks, against which external tools, and how do we prove it after the session gets resumed three times?

That sounds like enterprise wallpaper until the first agent incident. Then the boring surfaces become the only surfaces that matter.

Anthropic’s latest Claude Code release, published June 4 at 21:52 UTC, adds managed requiredMinimumVersion and requiredMaximumVersion settings, a new /plugin list command, better hook continuation semantics, and session-id continuity for stdio MCP servers under --resume. It also fixes a batch of runtime edge cases around background agents, Bash path-denial rules, provider auth in CI, Windows/OneDrive behavior, and temp-directory handling under Bazel and EDR-protected Go workflows.

Read as a normal changelog, it is a bundle of small fixes. Read as agent infrastructure, it is a control-plane release.

Version policy is no longer a polite suggestion

The most important change is that organizations can now set both a minimum and maximum supported Claude Code version through managed settings. If the local binary falls outside that window, Claude Code refuses to start and directs the user toward an approved version.

The minimum version is obvious. A stale coding-agent runtime may carry broken permission semantics, bad path matching, MCP bugs, or logging behavior the organization has already decided is unsafe. “Please update” is not a policy. It is a hope with a changelog attached.

The maximum version is the more mature move. Fast-moving agent runtimes can regress, and Claude Code has been shipping at a pace where a patch release may materially change hooks, permissions, plugin behavior, background-agent recovery, or provider auth. Some teams need latest. Many teams need “tested.” A maximum version lets platform teams pin a safe ceiling while they validate the next build against their own MCP servers, hooks, plugins, and managed-policy setup.

This is how coding agents start to look less like personal productivity tools and more like CI runners, browsers, endpoint agents, and developer IDE distributions. The binary version becomes part of the trust boundary. If an agent can edit files, run tools, call MCP servers, and operate across background sessions, the organization needs an enforceable version window, not a Slack reminder.

Plugins are now an inventory problem

The new /plugin list command, including --enabled and --disabled filters, looks modest. It is not.

Claude Code plugins can package skills, custom agents, hooks, MCP server configuration, LSP servers, monitors, executables added to PATH, and default settings. That means a plugin is not just a nicer command palette. It can be a toolchain extension, a policy surface, a local execution path, and a supply-chain object. If an agent behaves strangely, “which plugins were active?” should be near the top of the incident checklist.

Inventory is the first step toward governance. Teams should record installed and enabled plugins per project, restrict untrusted sources, review plugin contents like they would review devcontainer files or CI actions, and include plugin state in support bundles. The agent ecosystem keeps rediscovering that convenience packaging becomes supply chain the moment it can influence execution. Claude Code’s list command does not solve plugin trust. It gives teams the primitive required to start asking the right questions.

Hooks get a cleaner way to say “not done yet”

The hook change is subtle and useful. Stop and SubagentStop hooks can now return hookSpecificOutput.additionalContext to give Claude feedback and keep the turn going without being treated as a hook error.

That matters because hooks are where real teams will put review gates, test gates, cost gates, policy checks, and workflow supervision. Before this, a hook that wanted to intervene risked abusing failure semantics: fail the hook, hope the model reads the message, continue awkwardly. Now the hook can provide structured continuation context. It can say, in effect: the run is not complete, here is what the gate found, keep working.

This is a healthier control loop. Agents do not need more magical autonomy; they need lifecycle checkpoints that are explicit, inspectable, and owned by the team. A stop hook that can steer rather than merely fail is exactly the kind of small runtime primitive that makes longer-running agent work less chaotic.

MCP session identity is auditability, not tidiness

The release also fixes a session-continuity gap: stdio MCP servers now receive the same CLAUDE_CODE_SESSION_ID as hooks and Bash when running under --resume.

That is the sort of line item people skip until they need logs. MCP servers increasingly connect agents to GitHub, Slack, databases, dashboards, ticketing systems, cloud APIs, and internal tools. If a Claude Code session is resumed and the MCP server sees a different identity than the shell and hooks, audit trails fragment. Per-session caches get weird. Temporary resources become harder to reconcile. A post-incident question as basic as “which agent run did this?” becomes unnecessarily expensive.

Session IDs are not glamorous, but continuity is the backbone of agent observability. If background agents, resumed sessions, hooks, Bash commands, and MCP tools all participate in the same run, their logs need to agree on that run. Otherwise the organization has telemetry-shaped confetti.

The rest of v2.1.163 reinforces the same theme: agent runtimes fail at seams. A regression from 2.1.154 caused Bazel and EDR-protected Go workflows to fail because $TMPDIR was globally overridden to /tmp/claude-{uid} instead of only sandboxed commands. claude -p could demand ANTHROPIC_API_KEY in CI even when running through Bedrock, Vertex, or Foundry. Bash commands on Windows could fail with EEXIST when the session-env directory was read-only or inside OneDrive. Hook matchers like if: "Bash(...)" could fire too broadly on commands containing $() or $VAR. Home-directory deny rules such as Read(~/Desktop/**) now block Bash references through $HOME.

That last fix is a useful reminder: users think in semantic paths; shells think in expansions; permission systems must reconcile both. If a policy blocks ~ but not $HOME, it is not a policy. It is a spelling preference.

For teams using Claude Code seriously, the action list is concrete. Update a test cohort to 2.1.163. Decide whether managed minimum and maximum version windows belong in your org policy. Add plugin inventory to your audit checklist. Test Stop and SubagentStop hooks as review gates rather than error hacks. Verify MCP logs preserve stable session IDs across --resume. Regression-test path denies with ~, $HOME, symlinks, Windows paths, OneDrive directories, and shell substitutions.

The broader point is simple: agent runtime governance is not a future enterprise checkbox. It is what keeps a helpful coding assistant from becoming an untracked second operator in your engineering system. v2.1.163 is boring in the way a good lock, audit log, and version policy are boring. You only call it boring when it works.

Sources: Anthropic Claude Code v2.1.163 GitHub release, Claude Code settings docs, Claude Code hooks reference, Claude Code plugins docs, Claude Code MCP docs