claude-code - 💡(How to fix) Fix /mcp list view shows "connected" for HTTP MCP servers that lack valid OAuth — auth state not surfaced

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

The /mcp server list shows a "✓ connected" status that reflects only handshake reachability, not authentication state. An HTTP MCP server with invalid or missing OAuth credentials still renders as "connected" in the list, even though the model cannot use any of its tools. The detail view's Auth: ✗ not authenticated line is the only place the real state surfaces.

Error Message

  1. HTTP MCP server is configured in ~/.claude.json under mcpServers.
  2. OAuth access token in the Claude Code-credentials keychain item expires and the refresh flow silently fails (or the mcpOAuth entry is absent entirely).
  3. User asks the model to use a tool from that server.
  4. Model correctly reports that the MCP is unavailable (its tools never loaded into the session manifest).
  5. User runs /mcp and the list view shows the server as "✓ connected".
  6. Opening the server's detail view shows Auth: ✗ not authenticated.
  7. Restarting Claude Code does not change the list-view status.

Root Cause

The /mcp server list shows a "✓ connected" status that reflects only handshake reachability, not authentication state. An HTTP MCP server with invalid or missing OAuth credentials still renders as "connected" in the list, even though the model cannot use any of its tools. The detail view's Auth: ✗ not authenticated line is the only place the real state surfaces.

RAW_BUFFERClick to expand / collapse

Summary

The /mcp server list shows a "✓ connected" status that reflects only handshake reachability, not authentication state. An HTTP MCP server with invalid or missing OAuth credentials still renders as "connected" in the list, even though the model cannot use any of its tools. The detail view's Auth: ✗ not authenticated line is the only place the real state surfaces.

Environment

  • Claude Code: 2.1.119
  • macOS: 26.4 (Build 25E246)
  • Affected: all HTTP MCP servers whose initialize method doesn't require auth. Observed with Granola (https://mcp.granola.ai/mcp).

Observed behavior

  1. HTTP MCP server is configured in ~/.claude.json under mcpServers.
  2. OAuth access token in the Claude Code-credentials keychain item expires and the refresh flow silently fails (or the mcpOAuth entry is absent entirely).
  3. User asks the model to use a tool from that server.
  4. Model correctly reports that the MCP is unavailable (its tools never loaded into the session manifest).
  5. User runs /mcp and the list view shows the server as "✓ connected".
  6. Opening the server's detail view shows Auth: ✗ not authenticated.
  7. Restarting Claude Code does not change the list-view status.

Expected

The list-view status should reflect whether the server is usable end-to-end, not just whether the URL is reachable. At minimum, the list should visually distinguish "connected + authenticated" from "connected but auth broken".

Actual

List status appears to be derived from handshake reachability alone and does not incorporate auth state. A user scanning /mcp has no way to tell which servers are actually usable without drilling into each server's detail view.

Evidence that list-view status is decoupled from auth

  • Deleted the Granola mcpOAuth entry from the Claude Code-credentials keychain item so no OAuth state remained.
  • Started a fresh Claude Code session.
  • /mcp list view still showed Granola as "✓ connected".
  • Granola detail view correctly showed Auth: ✗ not authenticated.
  • Model's tool manifest contained zero mcp__granola__* tools for the session.

Suggested fix

Surface auth state in the list view. Possible forms:

  • Combined glyph: ✓ ready / ⚠ auth required / ✗ unreachable
  • Secondary label: granola · ✓ connected · ⚠ auth required
  • Don't render "connected" when any step required for tool availability has failed.

Additionally, consider auto-triggering the OAuth re-prompt when a configured server's access token has expired and refresh has failed, rather than leaving it in a silently-unusable state until the user discovers it manually.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix /mcp list view shows "connected" for HTTP MCP servers that lack valid OAuth — auth state not surfaced