Interactive MCP OAuth re-auth (/mcp) for an HTTP plugin server is not persisted for headless (claude -p) runs

Resolved 💬 2 comments Opened Jun 11, 2026 by loliphant Closed Jun 11, 2026

Summary

After re-authenticating an OAuth-based HTTP plugin MCP server via /mcp in an interactive session (status shows "Authentication successful. Connected"), the credential is not persisted in a form that headless claude -p runs can use. The server tools never mount in -p runs, even though they work fine interactively. Other OAuth MCP servers (which have a persisted clientId in ~/.claude/.credentials.json) DO mount in the same headless runs, which isolates the problem to per-server credential persistence.

Environment

  • Claude Code 2.1.173
  • macOS (Darwin 25.5)
  • Affected server: an OAuth HTTP MCP server provided by a plugin (the hosted Slack MCP at https://mcp.slack.com/mcp)

Repro

  1. Configure an OAuth HTTP plugin MCP server and confirm it works interactively (claude mcp list shows it Connected; its tools are available in an interactive session).
  2. Run headless: claude -p "list your MCP tools" --allowedTools "mcp__<server>". Its tools do NOT appear — only an auth-only connector exposing authenticate / complete_authentication. Waiting 3+ minutes does not help; other OAuth servers finish connecting in that window, this one never exposes tools.
  3. Interactively run /mcp, select the server, clear authentication, then authenticate (browser OAuth completes; "Authentication successful. Connected").
  4. Re-run the headless probe from step 2. Still no tools.

Evidence

  • ~/.claude/.credentials.json mtime does NOT change across the interactive clear+re-auth in step 3 — nothing is written for this server.
  • In ~/.claude/.credentials.json, the mcpOAuth entry for this server has serverName, serverUrl, discoveryState, and an empty accessToken, but NO clientId and NO redirectUri. OAuth servers that DO mount headless (for example a Glean or Atlassian HTTP MCP) have a persisted clientId and redirectUri in the same file.
  • This previously worked headless for about a week, then stopped after the credentials file was rewritten — suggesting the persisted OAuth client registration for this server was lost, and interactive re-auth does not restore it.

Expected

Interactive re-authentication should persist whatever credential / client registration a headless claude -p run needs, so a server usable interactively is also usable headless (as other OAuth MCP servers are).

Actual

Interactive re-auth connects the server only for the interactive session. Headless runs cannot bring it up (no persisted client registration), so automation using claude -p silently loses access to that server tools and falls back to an auth-only connector with no error.

Impact

Breaks unattended / cron use of affected OAuth plugin MCP servers; the failure is silent (the tools are simply absent).

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗