Sign up
View stargazersSign up

[Bug]: New Claude sessions keep a reconnected claude.ai connector as "needs authentication" for up to 4 hours#28568

opened12d agobyKkhaledDiZ

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Related but different: #19471 asked for reconnecting an MCP server inside a running session, and was moved to Ideas because Stop-then-resend (a new Claude process) is the supported path. This report is about that supported path: for claude.ai connectors, a new Claude process still does not pick up the reconnected connector.

Area

apps/server

Steps to reproduce

  1. Have a claude.ai connector (for example Sentry) whose sign-in has lapsed.
  2. Start a Claude thread in T3 Code. The connector is listed as needing authentication. That is correct so far.
  3. Reconnect the connector at claude.ai → Settings → Connectors.
  4. Start a new Claude thread, or Stop and resend in the old one. Both start a new Claude process.

Expected behavior

The new process connects the connector. The Claude desktop app does this right after the user reconnects.

Actual behavior

Every new Claude thread keeps reporting the connector as "requires authentication" for up to 4 hours. Its tools never load, so the only workaround is to use another app.

Cause: when a claude.ai connector fails its sign-in, Claude Code writes it to ~/.claude/mcp-needs-auth-cache.json. Every new process then skips that connector without dialing it until the entry expires. In Claude Code 2.1.316 the expiry is 4 hours for claudeai-proxy servers and 15 minutes for other servers. Reconnecting on claude.ai does not clear the entry. Only an explicit reconnect does. Interactive Claude Code exposes that reconnect through /mcp, and the desktop app through its own connector bridge. A Claude thread in T3 has no way to trigger it.

The Agent SDK that T3 bundles already has the call: Query.reconnectMcpServer(name). It dials the connector for real and removes the cache entry when that succeeds. ClaudeAdapterV2 never calls it.

Impact

Major degradation or frequent failure

Version or commit

T3 Code 0.1.6 (2359643cffa6); main @ 37d7615a

Environment

macOS 26 (Darwin 25.4), T3 Code desktop 0.1.6, Claude Code CLI 2.1.316, @anthropic-ai/claude-agent-sdk 0.3.276

Logs or stack traces

shell
1# Times are local (UTC+3).
2# 09:37:13 First Claude thread starts. claude.ai Sentry is pending, then fails its sign-in.
3# ~/.claude/mcp-needs-auth-cache.json gets "claude.ai Sentry": {"timestamp": <09:37:14>}
4# 09:41 Sentry reconnected on claude.ai
5# 09:48:56 New Claude thread. The first system/init already reports, without dialing:
6# claude.ai connectors in init: 28 {pending: 8, needs-auth: 20} Sentry: needs-auth
7# 09:51, 10:36 Further new threads: same result. The cache timestamp is still 09:37:14.
8
9# Same CLI driven through the Agent SDK with no model turn:
10# mcpServerStatus() -> claude.ai Sentry: needs-auth
11# reconnectMcpServer("claude.ai Sentry") -> resolves in ~1.5 s
12# mcpServerStatus() -> claude.ai Sentry: connected, 14 tools
13# cache entry for claude.ai Sentry -> removed

Status from mcpServerStatus() is the same for a connector stuck in that cache and one the user never authorized. Both look like {"status":"needs-auth","source":"claudeai","config":{"type":"claudeai-proxy",...}}. In the same session, a reconnect also brought back Google Docs, Google Sheets, Google Slides and Anthropic Economic Index. Those had been reported as needs-auth on every start. The other 15 connectors stayed needs-auth and their reconnects failed. A batch of 19 parallel reconnects took about 25 s in the background.

Workaround

Delete the connector's entry from ~/.claude/mcp-needs-auth-cache.json (or wait 4 hours), then start a new thread.

KkhaledDiZ6d ago
Synced from GitHub

@maria-rcks @juliusmarminge any plans for this ? Its very annoying