Anthropic released Claude Code 2.1.231 on 13 August 2026 with a tightly scoped but operationally important fix: MCP OAuth sign-in could fail when a server used a pre-registered OAuth client because Claude Code supplied a redirect URI that did not match the one registered by the provider. Anthropic names Slack as an example.

This is not a report of an attacker bypassing OAuth. It is the opposite: the authorization server rejected a request whose identity plumbing did not line up. The security control worked, but the integration did not. For organisations turning Model Context Protocol connections into centrally managed enterprise infrastructure, that distinction is important—and so is the outage it can cause.

MCP is becoming enterprise infrastructure. That means redirect URIs, client registration, scopes and token lifecycle are now part of the agent security boundary.

What Anthropic changed

The Claude Code 2.1.231 changelog says the release fixes MCP OAuth sign-in failing with a redirect URI mismatch for servers using a pre-registered OAuth client. A pre-registered client is one whose identifier, callback locations and other metadata have already been agreed with the authorization server. It is a common enterprise pattern because the provider can govern the integration instead of accepting an arbitrary client at runtime.

The fix follows a related change in 2.1.229, where Claude Code switched from localhost to 127.0.0.1 in its redirect URI for strict authorization servers. That earlier note should not be treated as the complete explanation for the 2.1.231 defect: Anthropic describes them as separate fixes. Together, however, they show how literal OAuth implementations can be. Two loopback addresses may reach the same machine while still being different URI strings and different registered destinations.

Before 2.1.231, Claude Code could send a callback URI that differed from the provider’s pre-registered value. Exact validation correctly stopped the authorization flow. The patch restores the expected match so OAuth can complete.

Why the provider rejects the request

OAuth uses the redirect URI to decide where the authorization server may return an authorization code after a user approves access. That code is valuable: it is exchanged for tokens that allow a client to act within the approved scopes. Sending it to an unexpected destination would risk handing the next stage of the login flow to the wrong application.

The MCP authorization specification therefore requires an authorization server to compare the redirect URI in the request with the client’s registered values and to reject a mismatch. Exact string matching is intentional. It limits redirect manipulation, code theft and open-redirector-style abuse. In this incident, Claude Code and the provider disagreed about the callback; the provider did what it was supposed to do and refused to continue.

This is why apparently boring implementation details have outsized effects. A valid user can have the right enterprise account, the correct MCP server and an approved OAuth client, yet still be unable to connect because one URI differs. From the user’s perspective the connector is broken. From the authorization server’s perspective the request is unsafe.

Why pre-registration matters for enterprise MCP

The MCP specification supports several ways for a client to become known to an authorization server. Pre-registration is the most controlled: an administrator or provider establishes the client in advance and distributes its identifier through trusted configuration. Client ID Metadata Documents and Dynamic Client Registration provide more automated alternatives, but they introduce different discovery, provenance and lifecycle questions.

For a service such as Slack, pre-registration makes sense. The provider can know which application is requesting access, which callbacks are allowed and which policies apply before an employee begins sign-in. Security teams can review one managed integration instead of allowing each local Claude Code installation to invent a new client relationship.

The trade-off is configuration rigidity. The registered metadata and the client’s runtime behaviour must remain aligned across releases, operating systems and deployment models. A change that looks harmless in a local CLI—different loopback hostname, port handling, callback path or scheme—can invalidate the enterprise registration.

The agent identity boundary is larger than login

OAuth does not merely get the user past a sign-in screen. It links an identity, a client, a resource server and a set of delegated permissions. In an MCP deployment, that relationship determines which corporate tools and data an agent can reach. Once the connection succeeds, Claude Code may be able to search messages, read records or invoke actions within the scopes granted to the integration.

That makes the complete token lifecycle part of agent security: how clients are registered, how users authenticate, how consent is recorded, how scopes are constrained, where tokens are stored, whether refresh tokens rotate, how resource audiences are enforced and how access is revoked. A perfect redirect does not compensate for a bearer token exposed in logs or a connector granted excessive scope.

The MCP security guidance also requires clients to use PKCE, validate state and avoid blindly forwarding tokens to downstream servers. Those controls address different attack paths. The lesson from 2.1.231 is not that redirect validation is uniquely important; it is that the whole authorization chain must remain coherent as agent clients and SaaS integrations evolve independently.

What enterprise teams should do now

  • Prioritise Claude Code 2.1.231 where pre-registered MCP integrations are in use, especially if Slack or another strict OAuth provider has recently failed during sign-in.
  • Inventory the exact redirect URIs registered for each MCP OAuth client. Treat the scheme, hostname, port and path as security-sensitive configuration, not informal documentation.
  • Test authentication in the real managed environment after upgrades. Local success does not prove that centrally registered clients, proxies or policy-enforcing gateways will accept the same request.
  • Keep client registration under administrative ownership and record who can change redirect URIs, scopes and credentials. Changes should be reviewed and auditable.
  • Grant the narrowest SaaS scopes the MCP server needs, use short-lived access tokens where supported and define a tested revocation path for the client and individual users.
  • Monitor repeated redirect mismatch errors as both an availability signal and a possible configuration-tampering indicator. Do not weaken exact-match validation to make an integration work.
  • Validate PKCE, state handling, token audience and secure token storage alongside the redirect configuration. OAuth assurance is a chain, not a single field.

The wider lesson

Enterprise agents are becoming identity-rich systems. They act through a user, an agent client, an MCP server and one or more corporate services, each with its own idea of trust. The interfaces between those identities are where small inconsistencies become outages—and where permissive workarounds can become security failures.

Claude Code 2.1.231 is therefore a modest patch with a useful signal. MCP connectors cannot be treated as lightweight plug-ins. They are delegated-access infrastructure. Organisations need to manage their client registrations, redirect destinations, scopes, tokens and revocation paths with the same discipline they apply to any other enterprise identity integration.