[BUG] All claude.ai connectors drop mid-session as a group and silently re-appear a few turns later (no /mcp, no restart) - started ~Aug 5, 2026

## Summary

Since around August 5, 2026, the full set of claude.ai remote connectors repeatedly becomes unavailable in the middle of a Claude Code session, then becomes available again a few turns later without any user action — no /mcp, no session restart, no re-auth.

This differs from the existing reports in one important way: recovery is automatic. The known issues describe drops that require manual /mcp (#24350) or that never recover at all (#61052). Here the connectors come back on their own, usually within a few turns.

The drop is not per-connector. All claude.ai connectors go away in one event and return in one event, including ones that were never called in the session.

Environment

• Claude Code 2.1.227 (also observed on 2.1.224)
• Windows 11, Microsoft Windows [Version 10.0.26200.8893], win32
• Installed via WinGet (Anthropic.ClaudeCode)
• Connectors are claude.ai remote connectors (not local stdio MCP servers)
• Local stdio MCP servers in the same sessions are not affected — they stay up while the claude.ai ones disappear

What it looks like

Mid-session, a system message reports the tools are gone:

434 deferred tools are no longer available (MCP server disconnected):
mcp__claude_ai_Atlassian_Rovo__* (40), mcp__claude_ai_Cognee__* (11),
mcp__claude_ai_Consensus__*, mcp__claude_ai_Gmail__* (16),
mcp__claude_ai_Google_Calendar__* (9), mcp__claude_ai_Google_Drive__* (8),
mcp__claude_ai_Home_Assistant__* (11), mcp__claude_ai_Linear__* (57),
mcp__claude_ai_Outline__* (19), mcp__claude_ai_Paperless__* (2),
mcp__claude_ai_PubMed__* (7), mcp__claude_ai_Zabbix__* (237),
mcp__claude_ai_Zoom_for_Claude__* (12)

While in that state, ToolSearch with select:mcp__claude_ai_Atlassian_Rovo__getJiraIssue returns No matching deferred tools found, so the tools genuinely cannot be called.

A few turns later, without anything being done about it:

430 deferred tools are available again (MCP server reconnected — names announced earlier in this conversation)

Note the tool counts differ between the drop and the return (434 vs 430, 438 vs 432 in another instance), so the set is not restored identically.

Steps to reproduce

I have no deterministic trigger. Observed pattern:

1. Start a Claude Code session on Windows with several claude.ai connectors enabled.
2. Work normally for a while, using at least one connector (in my case Jira via the Atlassian connector).
3. At some point the group-drop message appears mid-turn.
4. Continue working; a few turns later the group-restore message appears.

It happens several times per working day, but not at a fixed interval, and not tied to any particular tool call — it has occurred both right after a connector call and after long stretches of purely local work (file edits, bash).

Frequency data

I went back through 44 local session transcripts (~/.claude/projects/.../*.jsonl) from June 3 to August 12, 2026, and counted sessions where a ToolSearch for Atlassian tools returned No matching deferred tools found — i.e. the connector was provably absent at that moment.

| Period | Sessions using Jira | Sessions with a failure |
|---|---|---|
| Jul 13 – Aug 3 (3 weeks) | 17 | 1 (Jul 16) |
| Aug 5 – Aug 12 (1 week) | 27 | 6 |

Dates with failures: 2026-07-16, 2026-08-05 (×2), 2026-08-10 (×2), 2026-08-11, 2026-08-12.

This undercounts the real frequency: it only catches drops where I happened to call a connector during the outage window. Drops that started and ended between two connector calls leave no trace in the transcript.

Relation to Claude Code updates

The onset does not line up with a client update:

| Date | Event |
|---|---|
| Aug 5 | failures start (2 of 3 sessions) |
| Aug 8 | Claude Code updated to 2.1.224 |
| Aug 10 | 2 failures |
| Aug 11 | Claude Code updated to 2.1.227 |
| Aug 12 | 1 failure |

Failures began three days before the first update in that window, and neither update changed the behaviour. Combined with the fact that all connectors drop together — including unused ones — this points at the service side rather than the CLI.

Why this isn't the existing issues

• #24350 (silent drops needing manual /mcp) — closed as duplicate; there recovery requires user action, here it is automatic.
• #48557 (stale Mcp-Session-Id after server restart) — closed; there tools stay listed but every call errors, here the tools vanish from the list entirely and later return.
• #61052 (Claude Desktop closing stdin on mcp-remote) — closed as not planned, Claude Desktop, and explicitly no auto-recovery.
• #53489 (Claude Code Web losing connectors, ~Apr 23) — different surface and a permanent loss, not an intermittent one.

Expected behaviour

Either the connector session should not drop mid-session in the first place, or — if a drop is unavoidable — the reconnect should be transparent, so a tool call issued during the window is retried against the restored connection instead of failing with "no matching tools".

Impact

Not fatal, since waiting a turn or two restores things, but it interrupts multi-step work: a workflow that reads a Jira ticket, acts on it, and writes a comment back can fail halfway with no obvious cause, and the natural reaction (assume the connector needs re-authorising) sends you off investigating something that isn't broken.

I'm happy to run diagnostics during the next occurrence if there's a specific log or command that would help — just say which.