MCP OAuth fails with providers requiring HTTPS redirect URIs

Found 2 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/22649
2. https://github.com/anthropics/claude-code/issues/25246

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Issue was MCP OAuth always used http://localhost:<port>/callback as redirect uri.
So providers that require HTTPS redirect uri failed with redirect_uri mismatch.

Fix was simple.
I added support for oauth.redirectUri and used it in the OAuth flow.
I also made the callback listener use the same configured uri port.

Patch in my fork
https://github.com/yash27-lab/claude-code/tree/codex/mcp-oauth-redirect-uri-hotfix

Finding: OAuth failure state is cached in macOS Keychain, preventing retries (+ workaround)

If the initial OAuth browser prompt is dismissed or fails, Claude Code caches an empty token in the macOS Keychain under Claude Code-credentials. On subsequent session starts, it sees this entry and skips the OAuth flow entirely — the browser never opens again, even after uninstalling/reinstalling the plugin or clearing ~/.claude/mcp-needs-auth-cache.json.

The cached entry looks like:

{
  "mcpOAuth": {
    "slack|38801a7d845718b3": {
      "accessToken": "",
      "expiresAt": 0
    }
  }
}

Workaround that resolved it for me:

1. Clear the stale OAuth entry from Keychain:

```bash
# View current state
security find-generic-password -s "Claude Code-credentials" -w

# Write back without the slack entry (or empty JSON)
security add-generic-password -U -s "Claude Code-credentials" -a "$(whoami)" -w "{}"
```

1. Also clear ~/.claude/mcp-needs-auth-cache.json → {}
2. Uninstall and reinstall the plugin: claude plugin uninstall slack && claude plugin install slack
3. Start a new Claude Code session — browser opens, complete the OAuth flow this time

Suggestion for the devs: Claude Code should not cache an empty accessToken as a successful auth result. If the token is empty, it should retry the OAuth flow on next session start rather than silently skipping it.

Environment: Claude Code 2.1.72, macOS Darwin 25.3.0

This issue is actively blocking one of my production engineering workflows.

Environment:

• Claude Code 2.1.81 (latest) on macOS
• Slack workspace OAuth via MCP
• Exact error: redirect_uri did not match any configured URIs. Passed URI: http://localhost:3118/callback

Timeline:

• Slack MCP OAuth was working correctly as recently as Saturday, March 21, 2026.
• Failed starting Monday, March 23, 2026 with no client-side changes.

Additional data point:
A colleague (@derekrcohen) on a separate account is experiencing the identical redirect_uri mismatch error on a different integration — the Claude API console, not Slack. This suggests the issue is not workspace-specific or Slack-specific, but a broader OAuth callback problem in Claude Code.

Impact:
Claude Code's Slack MCP connection is a critical part of our agentic product engineering workflows. This is blocking multiple engineers.

The original issue reporter noted "this never worked," but it was working for us until this weekend, which suggests an OAuth provider (Slack or others) recently began enforcing HTTPS-only redirect URIs, triggering this pre-existing limitation.

Request:
Can the Claude Code team prioritize support for HTTPS localhost redirect URIs or provide a workaround? This is urgent for our team.

I tried a patch for this in my fork.

What I changed

I added support for oauth.redirectUri
I changed the OAuth flow to use that value instead of always forcing http://localhost:<port>/callback
I added a --redirect-uri option to claude mcp add
I also made claude mcp get show the configured redirect uri

What I tested

I built a patched package from the latest published CLI
I installed it locally
I ran claude mcp add with --redirect-uri https://localhost:3118/callback
I confirmed that value is saved in config and shown by claude mcp get

What I have not confirmed yet

I have not completed a full real provider OAuth flow with real credentials yet
So I am not claiming this fully resolves the issue
I am only saying this seems to address the hardcoded redirect uri path

https://github.com/yash27-lab/claude-code/tree/codex/mcp-oauth-redirect-uri-hotfix

If someone from the team can check whether this approach makes sense that would help

I'm experiencing the same issue. Claude Code uses http://localhost:3118/callback as the redirect URI, but Slack rejects it with "redirect_uri did not match any configured URIs." Running on Windows 11, Claude Code v2.1.81.

Temporary workaround: Using Claude Desktop (Cowork) as a Slack bridge

While waiting for the HTTPS redirect URI fix, I've established a workable interim approach using Claude Desktop's Cowork mode, which still has a functioning Slack MCP connector.

How it works:

• Claude Desktop's Slack connector authenticates via a different OAuth flow than Claude Code's MCP, and it's currently unaffected by this issue
• I use Cowork to read specified Slack channels (including private channels), expand all threads, and export the messages to a structured local markdown file with timestamps
• Claude Code can then ingest those local markdown files for downstream agentic workflows (daily planning, triage, etc.)

Benefits:

• Restores read access to Slack data for Claude Code workflows, albeit indirectly
• Structured markdown with Unix timestamps preserves thread context and is easy to parse programmatically
• Can cover multiple channels in a single pass

Limitations:

• Manual or semi-manual process — requires triggering the sync from Cowork rather than having Claude Code pull directly
• Read-only — no ability to send messages or react from Claude Code via this path
• Not real-time — it's a periodic snapshot, not a live connection
• Adds a dependency on Claude Desktop being available and authenticated
• Doesn't solve the root cause — HTTPS redirect URI support is still needed for direct Claude Code ↔ Slack MCP integration

This is not a substitute for fixing the underlying OAuth issue, but it's kept our agentic workflows running while we wait. Sharing in case it helps others who are blocked.

Update: Fully working again in both CLI and VS Code (v2.1.81)

As of today (March 23), Slack MCP is working in both the CLI (Terminal) and VS Code. The redirect_uri mismatch error I reported earlier is no longer occurring.

One UI quirk: the VS Code MCP servers panel still shows "Incompatible auth server: does not support dynamic client registration" and "Needs Auth" for Slack — but the tools actually work fine. The panel appears to attempt its own direct OAuth check (which fails at DCR), while the actual tool execution goes through Anthropic's MCP proxy and succeeds. Filed this UI issue separately at #3273.

Update: Got Slack MCP working on Windows 11, Claude Code v2.1.81.

The http://localhost:3118/callback redirect URI works fine when using the correct setup method. The primary blocker for Slack isn't the HTTPS redirect URI — it's the missing clientId in the setup command that most people are following.

What fails: claude mcp add --transport http slack https://mcp.slack.com/mcp — this omits the clientId, causing Claude Code to attempt dynamic client registration, which Slack rejects.

What works: claude plugin install slack — bundles the correct OAuth config including the pre-registered clientId and callbackPort.

Documented the docs/registry discrepancy in a separate issue: #38229

Related: #38102, #3273

Still reproducible. The redirectUri config field continues to be ignored — the core redirect URI mechanism needs to be fixed at source for providers that genuinely require HTTPS (Linear, GitHub apps, etc.). The claude plugin install path works as a workaround for Slack specifically, but that's not available for custom MCP servers. @yash27-lab's fork adds oauth.redirectUri support — would be great to see that merged upstream.

Four more MCP providers hitting the same redirectUri ignored bug since last check:

• #44301 — BigQuery MCP OAuth
• #48957 — Microsoft 365 MCP OAuth
• #52730 — Asana MCP OAuth
• #55067 — Slack (separate instance)

The oauth.redirectUri config field being silently ignored continues to affect every non-Slack provider. @yash27-lab's fork adding oauth.redirectUri support remains the clearest fix path.