Claude Code 2.1.129: plugins, model choice, and safer agent workflows

Claude Code is moving fast from “smart terminal” to governed agent platform. Today’s strongest signal is not only that version 2.1.129 is out, but that Anthropic is tightening how plugins, models, history, skills, and policy errors behave. For Swedish companies that want coding agents in real systems, this is a good moment to move from curious testing to controlled workflow design.

Source: Claude Code changelog 2.1.129

What actually changed

Claude Code 2.1.129 was published on May 6, and npm showed package version 2.1.129 as published roughly eleven hours before this check. That makes it reasonable to treat this as a current release, not just an older ecosystem signal.

The most practical changes:

• Session-scoped plugins from URL: the --plugin-url <url> flag can load a plugin archive for the current session.
• Gateway models now require an explicit choice: /v1/models discovery in the /model picker is now opt-in with CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1.
• Package-manager auto-update: CLAUDE_CODE_PACKAGE_MANAGER_AUTO_UPDATE can be used for Homebrew and WinGet installations.
• Working skillOverrides: teams can hide, limit, or shorten skills so the model does not automatically see everything.
• Better observability: the OTel metric claude_code.pull_request.count now includes PRs and MRs created through MCP tools.
• Clearer policy failures: policy refusal errors now include the API Request ID, making troubleshooting and support faster.

Source: GitHub releases for anthropics/claude-code and the @anthropic-ai/claude-code npm package

Why this matters for automation teams

The direction is clear: Claude Code is becoming more modular, but also more dependent on governance. Plugins can speed up experiments. Gateways can expose more model choices. MCP can connect the agent to GitHub, databases, and internal systems. But every extra connection is also a new surface for permissions, traceability, and vendor control.

For a Swedish business, the question is therefore not “should we use coding agents?” but “which agent workflows can we allow without creating untracked changes, data leakage, or hard-to-explain costs?”.

A good first step is to separate three types of Claude Code runs:

• Local developer assistance: the agent may read the project, suggest changes, and run tests after approval.
• Controlled repository automation: the agent may create PRs, but only with specific MCP tools and clear logs.
• Experimental plugin environment: new plugins may be tested in an isolated session, not installed permanently for the whole team.

Source: Claude Code Docs on MCP and allowedTools

The security lesson: project configuration is no longer passive

There is also important security context. Check Point Research earlier this year described how Claude Code project files, hooks, and MCP configuration could be abused for execution and token exfiltration before the vulnerabilities were patched. The point for teams today is broader than the individual CVEs: .claude/settings.json, .mcp.json, hooks, and plugin settings are operational code, not just “config”.

That is why every team trying 2.1.129 should add a simple governance routine:

• Review changes in .claude/ and .mcp.json as carefully as production code.
• Use allowedTools for MCP instead of broad permission modes when possible.
• Allow plugins only from known internal sources or reviewed archives.
• Log agent-created PRs and connect them to issue, repository, and accountable human owner.
• Test gateway model discovery as an explicit, documented choice.

Source: Check Point Research on Claude Code project files

What to test today

If you already run Claude Code in a team, do not change everything at once. Pick a repository where the consequence is low but the workflow is representative. Then test:

• Plugin from URL in a one-off session: use it for demos or evaluation, not as the default path for permanent team tooling.
• Gateway choice: enable model discovery only in a controlled environment and document which models appear.
• Skill limiting: try skillOverrides to see whether the agent becomes clearer when fewer internal instructions are exposed.
• MCP measurement: check whether PRs created through MCP show up in your OTel flows.
• Policy troubleshooting: save the API Request ID when Claude Code refuses an action so support and platform owners can recreate the event.

The goal is not to maximize autonomy. The goal is to find the smallest safe agent loop that actually saves time.

Try this prompt this week

Use this prompt in Claude Code inside a repository where you are allowed to experiment. Run it first without broad bypass modes and let the agent propose, not automatically apply, risky changes.

You are my Claude Code reviewer for agentic coding automation.

Goal: assess whether this repository is ready for controlled use of Claude Code 2.1.129 with MCP and possible session-scoped plugins.

Work step by step:
1. Read the project’s `.claude/`, `.mcp.json`, package scripts, CI configuration, and README.
2. Identify anything that can affect command execution, external API calls, model choice, hooks, plugins, or PR creation.
3. Propose a minimal `allowedTools` policy for a safe first workflow.
4. List which files or settings must be reviewed in PR before a coding agent is used by the team.
5. Propose one test scenario where the agent may create a small PR, run tests, and leave traceable logs.
6. Do not modify files until you have shown the plan and I have approved it.

Return the answer as:
- Risks to fix first
- Safe first MCP policy
- Recommended plugin rule
- Suggested first test PR
- Questions for the human owner

How to evaluate the answer:

• It names concrete files, not just generic risks.
• It recommends narrow MCP permissions instead of full bypass.
• It distinguishes local development, PR automation, and experimental plugins.
• It ends with a plan a human can approve before the agent changes code.

What to watch next

Watch three tracks over the next few weeks: how quickly the plugin format stabilizes, how gateways and model choice are governed in enterprise environments, and how MCP permissions become measurable in standard observability tools. When those three pieces connect, Claude Code becomes less of an individual power tool and more of a production-adjacent automation channel.