Claude Code v2.1.231｜Slack の MCP OAuth が redirect URI で弾かれる問題を修正｜毎日Changelog解説Claude Code v2.1.231 fixes a bug where MCP servers using pre-registered OAuth…

Anthropic has shipped Claude Code v2.1.231, a small maintenance release that contains a single fix aimed at users who connect the tool to external services through the Model Context Protocol (MCP). According to the release notes, the update resolves a bug that prevented MCP servers relying on pre-registered OAuth clients from completing sign-in, with Slack cited as the representative case. The failure was traced to a redirect URI mismatch during the authentication handshake.

The issue matters because OAuth-based sign-in is the gateway to many of the integrations that make Claude Code useful in day-to-day work. When the authentication step breaks, the affected MCP server cannot be authorized at all, which means the connected service is effectively unreachable from within the client. For teams that route their workflows through Slack or similar platforms, a redirect URI problem is not a cosmetic glitch but a hard blocker on getting the connection running.

To understand the fix, it helps to recall how the OAuth authorization flow works. When a user signs in to a third-party service, the authorization server sends them back to the application at a specific address known as the redirect URI, delivering an authorization code in the process. For security reasons, that redirect URI must exactly match a value the provider recognizes; if the value presented during the flow differs from what the server expects, the request is rejected outright. This strict matching is intentional, because it prevents authorization codes from being sent to an attacker-controlled destination. The trade-off is that even minor discrepancies cause the whole flow to fail.

The distinction that appears to sit at the center of this release is between dynamically registered and pre-registered OAuth clients. Some MCP servers support Dynamic Client Registration, in which the client and its redirect URI are negotiated on the fly. Others, including Slack, require developers to register the OAuth client ahead of time with a fixed redirect URI configured on the provider's side. In that pre-registered scenario, Claude Code needs to present the exact redirect URI that was set up in advance. The v2.1.231 changelog indicates that this is precisely where the earlier behavior went wrong, causing the mismatch and the resulting authentication failure.

For readers less familiar with the surrounding technology, MCP is an open standard introduced by Anthropic to give AI assistants a consistent way to reach external tools, data sources, and services. An MCP server exposes a capability, such as access to a messaging platform, project tracker, or database, and a client like Claude Code consumes it. Because many of those services sit behind their own identity systems, OAuth is a common part of the connection process, and correct handling of its details is a prerequisite for the ecosystem to function smoothly. As more providers publish MCP servers, edge cases in authentication like this one are likely to surface and require targeted fixes.

Claude Code itself is Anthropic's command-line coding assistant, and the company has been publishing frequent incremental releases, with version numbers advancing rapidly as small changes land. This particular build is narrow in scope, described as carrying only the one fix rather than new features, which is typical of a patch that addresses a specific compatibility problem. Users who were unable to authenticate a pre-registered OAuth MCP server, most visibly Slack, should be the primary beneficiaries once they update.

The source for this write-up is a Qiita blog that translates and annotates Anthropic's official Claude Code changelog shortly after each release, so the details here reflect the vendor's own notes as relayed through that community coverage. As always with a single-line changelog entry, the exact internal cause and the precise code path involved are not fully detailed publicly, so some of the mechanics described above are inferred from how OAuth redirect URI validation generally operates rather than spelled out in the notes.

For anyone maintaining MCP integrations, the practical takeaway is straightforward. If sign-in to a service using a pre-registered OAuth client had been failing, upgrading to v2.1.231 is the recommended step, after which it is worth confirming that the connection completes and that the redirect URI configured on the provider side still matches what the updated client sends.