Claude Desktop (macOS): claude.ai chat loses local device tools when the user switches sessions; in-flight tool calls get no result for ~120 s

Environment

• Claude Desktop 2.31226.0, macOS 26.5.1, Apple M1 Pro
• A claude.ai Project chat that reaches the Mac through the desktop app (local MCP servers such as Desktop Commander, exposed to the chat as device tools)
• Several other sessions in the same desktop app, used in rotation through the day

What happens
Local tool calls from the chat work for a short while after the user sends a message in that chat. Once the user moves to another conversation or session in the desktop app, later tool calls in the same turn return:

No result received from client-side tool execution after waiting 120 seconds. The client may have disconnected or the tool may be unresponsive.

The command content makes no difference. A bare echo ping fails minutes after a long diagnostic succeeded, then succeeds again seconds after the user's next message in that chat. Roughly a quarter of local tool calls were lost this way over three working days (6, 7 and 9 October 2026). In some cases the command never reached the Mac at all (a log file the command would have created did not exist afterwards).

Expected
A turn that is still running keeps its local tools while the user looks at another conversation, or the call fails immediately with a clear error instead of a silent two-minute wait.

Evidence from ~/Library/Logs/Claude/main.log (9 October, local time)

• 11:26:56 [remote-tools-device] keep-awake released (quiet, held 1100624ms)
• 11:27:09 LocalAgentModeSessions.sendMessage: sessionId=local_... followed by Starting local session local_... (the user sends a message in a different session)
• The chat's next local tool call, issued within the following two minutes, returned the 120-second error above.

The Mac itself was awake throughout (pmset: sleep prevented by Claude), with the app running.

Impact
Multi-session work is the user's normal workflow. Each drop stalls an agentic turn for two minutes and leaves multi-step work (builds, deploys) half done until the user returns to that chat and sends another message.

Possibly related
#58898, "LocalMcpServerManager kills active MCP process on session focus change" (opened 14 May 2026, closed 12 June 2026). The behaviour here looks similar on macOS with a cloud-hosted chat, so this may be a regression or a second path with the same effect.