MCP OAuth loopback redirect uses 127.0.0.1 instead of localhost — breaks providers (e.g. Salesforce) that only allow localhost callback URLs

Hit this too, on a different provider. Adding a few data points that aren't in the issue yet: the exact version this regressed in, an internal inconsistency in the same build, and the fact that it breaks a plugin shipped through Anthropic's own marketplace.

Regression range: 2.1.229

The host flipped between 2.1.228 and 2.1.229. Grepping the redirect-URI builder out of the native install bundles (~/.local/share/claude/versions/):

2.1.227  function yze(e=Qjs){return`http://localhost:${e}/callback`}
2.1.228               return`http://localhost:${e}/callback`
2.1.229  function eBr(e=m1a){return`http://127.0.0.1:${e}/callback`}

So this isn't long-standing behaviour — anything that authorized successfully on ≤2.1.228 and needs a fresh consent on ≥2.1.229 breaks.

It breaks the official Slack plugin

slack@claude-plugins-official v1.2.0 (installed from the claude-plugins-official marketplace; plugin authored by Slack) pins a static, pre-registered OAuth client rather than using DCR:

// .claude/plugins/cache/claude-plugins-official/slack/1.2.0/.mcp.json
{"mcpServers": {"slack": {
  "type": "http",
  "url": "https://mcp.slack.com/mcp",
  "oauth": {"clientId": "1601185624273.8899143856786", "callbackPort": 3118}
}}}

Because the client ID is fixed, the allowlist lives in Slack's app config and was registered as http://localhost:3118/callback. Slack string-matches redirect_uri (no RFC 8252 §7.3 loopback normalisation), so on 2.1.229 authorization dead-ends at:

Something went wrong when authorizing Claude. redirect_uri did not match any configured URIs. Passed URI: http://127.0.0.1:3118/callback

This affects every user of that plugin who hasn't already authorized, which makes it a bit more than a per-provider edge case.

Servers using client-id-metadata-document / DCR are unaffected, since the redirect URI is registered at authorize time — e.g. Linear's cached entry (clientId: https://claude.ai/oauth/claude-code-client-metadata) still holds "redirectUri": "http://localhost:3118/callback" and keeps working.

2.1.229 is internally inconsistent

The same build still uses localhost on the OIDC/IdP login path:

// MCP OAuth path
function eBr(e=m1a){return`http://127.0.0.1:${e}/callback`}
// OIDC/IdP path, same build
let i = e.callbackPort ?? await mPt(), s = `http://localhost:${i}/callback`

Worth aligning these whichever way the fix goes.

No host override exists

Confirming the issue's point: the adjacent env var is port-only, so there's no way to work around this via config.

function oMS(){let e=Q.MCP_OAUTH_CALLBACK_PORT; return e!==void 0&&e<=65535?e:void 0}

Workaround (confirmed working)

Authorize once on a 2.1.228 binary, then go back to current:

~/.local/share/claude/versions/2.1.228     # then /mcp -> authenticate

The token survives the upgrade because refresh grants don't carry redirect_uri (RFC 6749 §6). Only useful while an old version is still on disk, though — the version pruner will eventually remove it.

On the fix

Flipping the hardcode back to localhost just re-breaks the other direction — #82096 and #42765 asked for 127.0.0.1 precisely because some IdPs allowlist only the IP literal. Since the two provider populations are mutually exclusive, a single hardcoded host can't satisfy both. Options that do:

1. Bind the loopback listener once and register both http://localhost:<port>/callback and http://127.0.0.1:<port>/callback at DCR time, then send whichever the server's registered set contains (they resolve to the same socket, so no extra listener is needed).
2. Retry the authorize with the other host when the provider returns redirect_uri_mismatch / invalid_redirect_uri.
3. Make it explicit — an oauth.callbackHost alongside the existing oauth.callbackPort in .mcp.json, plus a matching env var. This also lets plugin authors pin the host their app registration actually uses, which is what the Slack case needs.

Happy to test a fix against both the Slack plugin and a DCR server if useful.

Env: Claude Code 2.1.229, native install, macOS 26.3 (darwin 25.3.0), arm64.

hit this as well

127.0.0.1 is the spec-correct choice. RFC 8252 §7.3 defines the loopback redirect using the IP literal (127.0.0.1 / ::1), and §8.3 explicitly says using localhost is NOT RECOMMENDED — it can inadvertently bind beyond loopback and is more susceptible to misconfigured host resolution. OAuth 2.1 carries the same guidance forward (it just tightens redirect URI matching in general, with loopback still getting the port-mismatch exception).

A config option to opt into localhost (with a warning) for providers that insist on it — Salesforce, for example, rejects IP-literal callbacks outright — is a reasonable compromise. But 127.0.0.1/::1 should stay the default.