[BUG] Desktop-launched sessions: claude.ai connector push (replaceRemoteMcpServers) is never applied to an in-flight turn — first turn of every fresh session has no connector tools

Environment

• Claude Desktop (Windows, non-MSIX install under AppData/Local/Claude), driving Claude Code remotely via SSH into WSL2 (Debian)
• Remote CLI: ~/.claude/remote/ccd-cli/2.1.246, CLAUDE_CODE_ENTRYPOINT=claude-desktop
• claude.ai account-level connectors: Atlassian, Context7, Microsoft 365, Microsoft Learn, Wrike, visualize (all connected and OAuth-authorized on claude.ai)

Summary

In Claude Desktop-launched sessions, the claude.ai connectors are not part of the CLI session's MCP configuration at spawn. The Desktop pushes them via replaceRemoteMcpServers immediately after spawn (and again on every focus change / message), but a turn that is already in flight never picks the push up — the connector tools only materialize at the next turn boundary (next user message or a background-task notification re-invocation). ToolSearch re-runs, waiting, and mid-turn retries never surface them.

Consequence: the first turn of every fresh Desktop session deterministically runs without any claude.ai connector tools. For long agentic first turns (e.g. a skill invoked as the opening message that runs 30+ minutes), the whole run silently loses Outlook/Teams/Wrike/Atlassian capabilities even though the connectors are healthy, and the model reports them as "unavailable".

Steps to reproduce

1. Connect several claude.ai connectors (e.g. Microsoft 365, Wrike) to the account; verify they work.
2. From Claude Desktop, open a new Claude Code session on a remote (SSH/WSL) target and make the first message a task that needs a connector tool (e.g. "search my Outlook calendar for today").
3. Observe the first turn: the connector tools are absent (ToolSearch by capability keywords finds nothing; the model falls back or reports the connector missing). Meanwhile the Desktop log shows the push happened.
4. Send any second message ("retry"). The tools are now present (UUID-prefixed, e.g. mcp__c2009dbf-…__outlook_calendar_search) and the same call succeeds immediately.

Reproduced deterministically across 4+ sessions on 2026-08-25/26/27.

Evidence

Desktop main.log, session start (timestamps Europe/Berlin):

10:46:40 Starting local session local_4a7bc12e-… in /home/re/git
10:46:40 [SSH] Using remote spawn function … (cli: ~/.claude/remote/ccd-cli/2.1.246)
10:46:40 [CCD] LocalSessions.replaceRemoteMcpServers: sessionId=local_4a7bc12e-…, serverCount=6
10:46:40 [CCD] [replaceRemoteMcpServers] Calling SDK with 6 total servers
         serverNames: [ 'Atlassian', 'Context7', 'Microsoft 365', 'Microsoft Learn', 'Wrike', 'visualize' ]
10:46:51 [CCD start-timing] local_4a7bc12e-… … mcp_count=0 … mcp_config=stdio:0/sdk:0/http:0 …
         init_mcp=connected:2/pending:1/failed:0/needs_auth:1/…   <-- only the 4 locally-configured servers

The push was repeated at 10:51, 10:55, 11:12, 11:15, 11:16 (each focus change) while the first turn was in flight — the tools never appeared to the model (verified live with repeated ToolSearch calls inside that turn, including +wrike task search → "No matching deferred tools found"). No error is logged anywhere for the dropped pushes.

The moment the user sent the next message (turn boundary), the session's deferred-tool list gained all ~75 connector tools (mcp__84763734-…__wrike_*, mcp__c2009dbf-…__outlook_*, mcp__5c5babde-…__*, …) with no other change.

Second pattern, showing a background-task notification also acts as the boundary (session from 2026-08-25):

• 06:55 first user message (fresh session) — M365 tools absent all turn
• 07:05:24 <task-notification> re-invokes the agent
• 07:05:40 mcp__c2009dbf-…__outlook_calendar_search succeeds

Expected behavior

Either of:

1. Connector servers are included in the session's MCP config at spawn (like locally-configured servers), so the first turn has them — matching terminal-CLI behavior, where the claude.ai-proxy connectors attach during init and ToolSearch waits for still-connecting servers; or
2. A mid-turn replaceRemoteMcpServers surfaces the new servers' tools to the in-flight turn the same way late-connecting HTTP servers do (deferred tools discoverable via ToolSearch).

Actual behavior

The push is silently queued (or dropped and only re-sent on focus change) and applies only at the next turn boundary. Nothing is logged as an error; from inside the session the connectors look nonexistent, which the model reasonably reports as "connector missing/not authenticated" — a misleading failure mode for users.

Related issues (checked — not duplicates)

• #67432 — background sessions spawned via spawn_task chips lack external MCP servers until the first user message (closed as not planned). Same symptom class, but that report is specific to the spawn_task init path; this one is about normal user-initiated sessions whose first message races the connector push.
• #79491 — a failed connector fetch is cached indefinitely, so the connector is missing from the push list (serverCount one short). Here the connectors are present in every push (serverCount=6 each time); the push itself is not applied mid-turn. Notably, #79491 observed that a manual connector toggle hot-injected the server into already-running sessions — so a mid-turn application path appears to exist but is not triggered by the spawn-time/focus-time pushes.
• anthropics/claude-ai-mcp#383 — first-turn tool-discovery race for local stdio servers in Cowork; same "agent wrongly concludes the connector isn't installed" failure mode, different transport.

Impact

Any workflow invoked as the first message of a fresh Desktop session (the normal way users start skills) runs its entire first turn without connector tools. Long single-turn agentic runs lose the capability for the whole run. The workaround (warm the session with a throwaway message, or have the skill end its turn against a pending background task and resume on the notification) works but is non-obvious.