Claude Code plugin governance routing: v2.1.195 closes consent and hook gaps

Claude Code plugin governance routing became a practical upgrade issue in v2.1.195. The release fixes plugin consent paths, hook matcher precision, and background-agent durability rather than announcing a new model. That is exactly why it matters. For teams operating coding agents through an AI gateway or enterprise developer fleet, Claude Code plugin governance routing is now about proving that every plugin, hook, Remote session, and long-running agent has the same trust boundary after an upgrade as it had before.

What happened in Claude Code plugin governance routing

Anthropic's official Claude Code v2.1.195 release landed on June 26 with a set of fleet-control fixes. The most important changes for operators are small individually but meaningful together:

• External plugins enabled only by project .claude/settings.json now require explicit install consent on every loader path.
• Hook matchers with hyphenated identifiers, such as code-reviewer or mcp__brave-search, no longer accidentally substring-match. They now exact-match, and teams should use patterns such as mcp__brave-search__.* when they intentionally want all tools from a hyphenated MCP server.
• /plugin Enable and Disable now work when a plugin's plugin.json name differs from its marketplace entry name.
• Background jobs no longer disappear from claude agents or lose data when written by a newer Claude Code version.
• Crashed background tasks reopen to their restart instead of a blank screen, and unreachable background-agent daemons no longer block restarts when the control socket fails to start.
• Remote session startup now shows a provisioning checklist while the container starts.
• CLAUDE_CODE_DISABLE_MOUSE_CLICKS can disable mouse click, drag, and hover in fullscreen mode while keeping wheel scroll.

The release follows a week of control-plane changes, including Claude Code shell classifier routing and Claude Code MCP reliability routing. v2.1.195 narrows a different surface: plugin trust, hook targeting, background-agent persistence, and Remote startup evidence.

Why Claude Code plugin governance routing matters

A plugin is not just a convenience bundle. In an enterprise coding-agent stack, it can carry skills, hooks, MCP server assumptions, commands, and workspace-specific behavior. If a project setting can enable an external plugin without explicit consent on one loader path, the operator has a policy gap. If a hook matcher accidentally catches a hyphenated name by substring, the gateway may over-apply or under-apply a safety control. If background jobs vanish after a version boundary, audit trails and cost attribution become unreliable.

Claude Code plugin governance routing therefore changes the upgrade checklist from "does the CLI launch?" to "can we prove the same plugin and hook policy was enforced across every workspace?" The answer has direct consequences for teams using coding agents with production repositories, customer data, or deployment credentials.

The hook change is especially important. Many teams use hooks to enforce linting, secret scans, command approvals, or MCP access policy. Exact-match behavior is safer than surprising substring matches, but it can also expose configurations that depended on the old behavior accidentally. After upgrading, operators should review every hyphenated hook target and decide whether it should match one tool, one agent, or an entire MCP server namespace.

Claude Code plugin governance routing policy

Treat the v2.1.195 upgrade as a policy migration. Start with plugin provenance. Every external plugin should have an owner, source, version, install-consent record, and workspace scope. Project-level settings are useful, but they should not become a silent bypass around fleet-level approval.

Then audit hook matchers. Split them into three classes:

1. Exact tool hooks for a single named tool or reviewer, where a hyphenated identifier should match only that target.
2. Namespace hooks for MCP servers, where a pattern like mcp__brave-search__.* is intentional and documented.
3. Deny or approval hooks for commands that can mutate code, read secrets, deploy infrastructure, or open network egress.

Background agents need a separate lane. A coding-agent gateway should keep durable records for session ID, workspace, plugin set, hook policy version, running command, owner, and last visible state. The v2.1.195 fixes make disappearance less likely, but the operator still needs independent evidence when a background task crosses an update, crash, or Remote container restart.

For TheRouter readers, the same pattern applies beyond Claude Code. A model router is not enough once coding agents become long-running processes with plugins and hooks. The operational unit is the session: model choice, tool surface, plugin provenance, hook policy, remote host, and background lifecycle should be routed together.

What TheRouter users should watch or try

Run a staged upgrade before pushing v2.1.195 to every developer machine or Remote host.

Use this checklist:

• Inventory external plugins enabled through .claude/settings.json and confirm explicit install consent appears on every loader path.
• Search hook configs for hyphenated identifiers and decide whether each one should be exact-match or namespace-wide.
• Add regression tests for high-risk hooks: secret scanning, deployment approval, package install approval, and MCP tool allowlists.
• Reopen background jobs created before and after the upgrade, then confirm claude agents still shows state, owner, and recoverable task data.
• Test a crashed background task and a failed control socket path in a disposable workspace.
• Verify the Remote provisioning checklist gives operators enough evidence to distinguish slow startup from broken setup.
• Keep internal links between this upgrade and the broader TheRouter docs model: agent routing policy should include tools, plugins, hooks, and background lifecycle, not only provider selection.

The practical takeaway is simple: Claude Code plugin governance routing turns small release-note fixes into a fleet-control requirement. If your coding agents can load plugins, match hooks, and keep working in the background, your gateway policy needs to route and audit those surfaces as carefully as it routes model calls.