Claude Code 2.1.136 Is a Patch Release With a Security Roadmap Hiding in Plain Sight

Patch releases are where agent products tell the truth about themselves.

Claude Code v2.1.136, released May 8, does not arrive with a benchmark chart, a cinematic demo, or a new model name to argue about on Hacker News. It is a long list of fixes: OAuth token races, MCP server persistence, plan-mode write boundaries, plugin resolution, terminal rendering, IDE state, and a new enterprise policy knob called settings.autoMode.hard_deny. That sounds like chores. It is also exactly where the serious product is being built.

The useful way to read this release is not as a grab bag of bug fixes. Read it as Anthropic tightening the runtime harness around Claude Code after a week in which the broader ecosystem was forced to look directly at MCP trust, repo-controlled configuration, and agent credentials. Adversa’s TrustFall research put project-scoped MCP configuration under a microscope. Mitiga’s MCP token-theft work showed how local Claude configuration and OAuth tokens can become a control-plane liability. Claude Code 2.1.136 is not a response note, but it lands in the same blast radius.

Hard deny is the enterprise primitive Claude Code needed

The most important line in the release is the addition of settings.autoMode.hard_deny, a new class of classifier rules that block actions unconditionally, “regardless of user intent or allow exceptions.” That wording matters. Most agent permission flows are built around negotiation: ask the user, show a prompt, let them allow once, let them persist an exception. That model works for low-risk local edits. It does not work for action categories an organization has already decided are off-limits.

Enterprises need policy primitives that do not care how persuasive the model is, how confident the user feels, or whether an old allow rule happens to match. A bank may want to hard-deny agent-initiated access to production credentials. A SaaS company may want to block deploy commands from auto mode. A security team may want to forbid repo-defined MCP servers from launching in unattended sessions. Those are not “ask me again” decisions. They are controls.

This is one of the quiet ways Claude Code is becoming less like a clever CLI and more like developer infrastructure. The model can remain flexible while the execution harness becomes stubborn. That is the right split. You want creativity in the plan, determinism in the guardrails.

Plan mode has to mean no writes

The sleeper fix is plan mode now correctly blocking file writes even when a matching Edit(...) allow rule exists. On paper, that is a bug fix. In practice, it is a trust repair.

Modes are part of the user interface’s security contract. When a tool says “plan,” the user’s mental model is: think, inspect, propose, but do not mutate the workspace. If an older permission rule can punch through that boundary, the UI is lying by omission. Nobody cares whether the resolver had a technically consistent reason. The human saw “plan mode.” The product owed them a non-writing session.

This is the recurring agent-security problem in miniature. The model is not necessarily malicious. The user is not necessarily careless. The failure happens in the mismatch between labels, policy resolution, tool permissions, and state inherited from previous work. Claude Code is complicated because real development environments are complicated. That is precisely why mode semantics need to be absolute enough that users can rely on them under pressure.

MCP state is now operational state

Several fixes revolve around MCP servers and connector state. Servers configured in .mcp.json, plugins, and claude.ai connectors no longer silently disappear after /clear in the VS Code extension, JetBrains plugin, and Agent SDK. /doctor now reports MCP schema errors with the missing field and source file path. /mcp server lists scroll when there are more servers than fit in the terminal. MCP tool results are visible when servers return content blocks.

These are the details that do not trend because they are only painful after adoption. A conversation reset should not change the agent’s tool topology. If a connector disappears after /clear, the next answer may be worse, slower, or wrong for reasons the developer cannot see. Teams will blame model quality when the actual bug is state drift. That is how agent systems become impossible to debug.

MCP is no longer an optional accessory in this ecosystem. It is the bridge between the agent and the systems developers actually use: ticket trackers, repos, docs, data stores, internal APIs, deployment metadata. Once a tool is in that position, its availability is production-ish state. It needs diagnostics, stable lifecycle behavior, and boring observability. Claude Code 2.1.136 moves in that direction.

OAuth reliability is a security feature

The release also fixes a rare login loop where concurrent credential writes could overwrite a freshly rotated OAuth token, plus a separate bug where MCP OAuth refresh tokens were lost when several servers refreshed concurrently. Anthropic says users with multiple remote MCP servers should no longer need daily re-authentication.

That may sound like convenience, but auth reliability and security are coupled. When developers are forced to re-authenticate constantly, they build workarounds. They keep sessions open too long. They paste tokens into places they should not. They disable integrations. They blame the enterprise identity provider. A flaky credential lifecycle creates pressure toward worse operational behavior.

Remote MCP servers make Claude Code more useful because they connect it to real systems. They also create a credential garden: refresh tokens, proxy configuration, plugin metadata, local config files, claude.ai connectors, and multiple concurrent sessions. The security boundary is not one prompt. It is the whole credential lifecycle. If that lifecycle breaks under concurrency, the product is not ready for serious fleet use.

The practitioner checklist

If your team uses Claude Code casually, this is still worth installing. If your team uses it in IDE integrations, SDK workflows, MCP-heavy setups, or anything close to auto mode, it is more than routine maintenance.

Upgrade a test group to 2.1.136 and specifically exercise /clear, /resume, plan mode, and MCP connector availability. Review auto-mode policy and decide which actions deserve hard-deny treatment rather than another approval prompt. Audit MCP OAuth flows for refresh-token churn before dismissing re-auth complaints as user error. Check plugin skill resolution if you package internal skills. And if you are embedding Claude Code in CI-like or SDK-driven workflows, add regression tests around mode boundaries and connector state.

The larger point is that agent governance is becoming normal software operations. You need policy, state inspection, upgrade testing, auth diagnostics, and incident muscle. “It is just a coding assistant” stopped being true the moment the assistant gained tools, credentials, plugins, MCP servers, and permission memory.

Claude Code 2.1.136 is not flashy. Good. Flashy is not what this layer needs. The release says Anthropic understands that the hard part of coding agents is no longer only the model’s ability to produce a patch. It is making sure the agent can be governed, debugged, resumed, constrained, and trusted when the repo, the IDE, the auth stack, and the tool graph all start moving at once.

Sources: Claude Code GitHub release v2.1.136, Claude Code changelog, Claude Platform release notes, Adversa TrustFall research, Mitiga MCP token-theft research