[BUG] Claude Desktop (Windows): local MCP tool calls freeze while the session tab is not visible; hosted calls and scheduled tasks unaffected
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Related (all closed or off-target): #48045 (same bug, auto-closed stale and locked before a fix), #57602 (session auto-archives on focus loss), #68625 (timeoutOnHidden lifecycle teardown traced in app.asar), #65643 (the 4-minute "No result received" timeout this bug triggers). Filing new because #48045 is locked.
What's wrong
In Claude Desktop on Windows, a local MCP tool call (stdio server: filesystem, mssql, Salesforce DX) issued from a chat or Cowork session does not start or complete while that session's tab is not the visible one. It resumes the moment the tab is shown. Hosted MCP calls (Atlassian, Microsoft 365) and model generation continue normally in hidden sessions. The identical local calls complete unattended when run from a Cowork scheduled task, and run instantly outside Claude.
With several sessions open, any local call in a non-visible session sits frozen until the user looks at it, and hits the 4-minute cap, producing "No result received from the Claude Desktop app after waiting 4 minutes. The local MCP server providing this tool may be unresponsive, crashed, or not running." The server is healthy; the message misattributes the cause.
Repro (2026-09-09, Windows 11, Claude Desktop current release, Team plan)
| Test | Session visible? | Result |
|---|---|---|
| mssql:execute_sql SELECT 1 | Yes, stayed on tab | Completed in ~14 s |
| Same call, switched to another session tab for ~2 min | No | Frozen at 2m+ on return; completed within ~2 s of tab becoming visible |
| Atlassian Jira search (hosted MCP), switched away ~2 min | No | Completed in background before return |
| Cowork scheduled task using the same mssql + Salesforce DX tools | Unattended | Completes reliably, several times daily |
| Same SQL via sqlcmd, same SOQL via sf CLI, outside Claude | N/A | 0 s / 2–3 s |
Restarting Desktop does not change the behaviour. Browser (claude.ai) sessions on this account do not expose local MCP servers, so there is no non-Desktop path for local tools. Desktop does not support multiple visible session windows (Ctrl+N opens a new chat, not a new window), so "keep it visible" is not a workaround when the workflow requires switching sessions.
Impact
Users running several Cowork sessions in parallel lose sessions to this timeout daily. On our side it cost two weeks of diagnosis (throughput, contention, relay health) before the visibility dependency was isolated with the tests above.
Environment
- Windows 11, wired network, corporate proxy (Zscaler)
- Claude Desktop: current release as of 2026-09-09
- Local MCP servers: filesystem (official), mssql, Salesforce DX
What Should Happen?
Local MCP tool calls issued from a session should proceed while that session's tab is hidden, the same way hosted MCP calls and model generation already do. If pausing hidden sessions is intentional, in-flight tool calls should be allowed to finish, and the UI should say "paused — session not visible" instead of reporting a server timeout that blames a healthy MCP server.
Error Messages/Logs
Steps to Reproduce
- Windows 11, Claude Desktop, with at least one local stdio MCP server configured (I used the official filesystem server and an mssql server; Salesforce DX shows the same behaviour).
- Open two chat sessions, A and B.
- In session A, ask Claude to run a trivial local MCP call (e.g.
mssql:execute_sqlwithSELECT 1, or a small filesystem read). Stay on tab A. Note the turn timer — completes in ~14 s. - In session A, ask for the same call again. Immediately click session B in the sidebar and stay there for ~2 minutes.
- Return to session A. Observe: the call is still in progress with the timer at 2m+, then completes within ~2 seconds of the tab becoming visible.
- Control: repeat step 4 with a hosted MCP call instead (e.g. an Atlassian Jira search). Return after 2 minutes — it has completed in the background.
- Control: run the same local call from a Cowork scheduled task with no session visible — it completes.
- Leave a local call in a hidden session for more than 4 minutes — it fails with "No result received from the Claude Desktop app after waiting 4 minutes" even though the server is healthy.
Claude Model
Opus
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.119
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
claude desktop
Showing cached comments. Read the full discussion on GitHub ↗
7 Comments
The hosted-call and scheduled-task controls make this look like a hidden-tab lifecycle issue, not an unhealthy local server. A log snippet from just before switching tabs through the moment it resumes could help show where execution stalls.
main.log from a reproduction on 2026-09-16 (Claude Desktop, Windows, packaged build). Session doing local work, hidden 10:40–10:42, returned to at 10:42:
The [process-memory] heartbeats continue on their ~60s interval throughout, so the app process is alive and unthrottled — it's specifically the agent VM that goes idle while the tab is hidden and wakes on focus. Consistent with the timeoutOnHidden lifecycle in #68625.
2026-09-16 10:39:33 [info] Failed to set title bar overlay, this is probably expected
2026-09-16 10:39:51 [info] Failed to set title bar overlay, this is probably expected
2026-09-16 10:39:51 [info] Failed to set title bar overlay, this is probably expected
2026-09-16 10:40:05 [info] [process-memory] trigger=interval tree_rss_sum=1599MB electron(8)=1599MB children(0)=0MB top=[electron_main:25196:476MB electron_renderer:12700:463MB electron_gpu:3980:188MB electron_utility:18112:121MB electron_utility:9640:108MB] sys_free=2700MB/16024MB sys_free_raw=2700MB
2026-09-16 10:40:05 [info] [process-memory] trigger=interval tree_rss_sum=1599MB electron(8)=1599MB children(0)=0MB top=[electron_main:25196:476MB electron_renderer:12700:463MB electron_gpu:3980:188MB electron_utility:18112:121MB electron_utility:9640:108MB] sys_free=2700MB/16024MB sys_free_raw=2700MB
2026-09-16 10:40:06 [info] Failed to set title bar overlay, this is probably expected
2026-09-16 10:40:06 [info] Failed to set title bar overlay, this is probably expected
2026-09-16 10:40:13 [info] [PluginsFetcher] fetchPluginEnabledState: 3 overrides
2026-09-16 10:40:13 [info] [PluginsFetcher] fetchPluginEnabledState: 3 overrides
2026-09-16 10:40:24 [info] [EventLogging] Flushing 6 events
2026-09-16 10:40:24 [info] [EventLogging] Flushing 6 events
2026-09-16 10:41:07 [info] [process-memory] trigger=interval tree_rss_sum=1575MB electron(8)=1575MB children(0)=0MB top=[electron_main:25196:474MB electron_renderer:12700:436MB electron_gpu:3980:194MB electron_utility:18112:121MB electron_utility:9640:108MB] sys_free=2695MB/16024MB sys_free_raw=2695MB
2026-09-16 10:41:07 [info] [process-memory] trigger=interval tree_rss_sum=1575MB electron(8)=1575MB children(0)=0MB top=[electron_main:25196:474MB electron_renderer:12700:436MB electron_gpu:3980:194MB electron_utility:18112:121MB electron_utility:9640:108MB] sys_free=2695MB/16024MB sys_free_raw=2695MB
2026-09-16 10:42:04 [info] [process-memory] trigger=interval tree_rss_sum=1574MB electron(8)=1574MB children(0)=0MB top=[electron_main:25196:471MB electron_renderer:12700:439MB electron_gpu:3980:194MB electron_utility:18112:121MB electron_utility:9640:108MB] sys_free=2928MB/16024MB sys_free_raw=2928MB
2026-09-16 10:42:04 [info] [process-memory] trigger=interval tree_rss_sum=1574MB electron(8)=1574MB children(0)=0MB top=[electron_main:25196:471MB electron_renderer:12700:439MB electron_gpu:3980:194MB electron_utility:18112:121MB electron_utility:9640:108MB] sys_free=2928MB/16024MB sys_free_raw=2928MB
2026-09-16 10:42:29 [info] [VM] getVMStorageSubpath: vmStorageDir=C:\Users\rrr\AppData\Roaming\Claude\claude-code-vm, subpath=c/Users/rrr/AppData/Local/Packages/Claude_pzs8sxrjxfjjc/LocalCache/Roaming/Claude/claude-code-vm
2026-09-16 10:42:29 [info] [VM] getVMStorageSubpath: vmStorageDir=C:\Users\rrr\AppData\Roaming\Claude\claude-code-vm, subpath=c/Users/rrr/AppData/Local/Packages/Claude_pzs8sxrjxfjjc/LocalCache/Roaming/Claude/claude-code-vm
2026-09-16 10:43:05 [info] [process-memory] trigger=interval tree_rss_sum=1630MB electron(8)=1630MB children(0)=0MB top=[electron_renderer:12700:492MB electron_main:25196:472MB electron_gpu:3980:195MB electron_utility:18112:121MB electron_utility:9640:108MB] sys_free=3301MB/16024MB sys_free_raw=3301MB
2026-09-16 10:43:05 [info] [process-memory] trigger=interval tree_rss_sum=1630MB electron(8)=1630MB children(0)=0MB top=[electron_renderer:12700:492MB
This narrows it down: the app stays alive while the VM goes quiet only when the tab is hidden, then resumes after focus returns. That points more to the hidden-tab lifecycle than to the MCP server itself; tracing visibility changes alongside VM/tool-result events should show where it pauses.
The app logs both the visibility change and the lifecycle transition you're asking about, under [SkillsPlugin] and [Lifecycle]:
So the app process stays alive and unthrottled; it's the per-session VM/polling that idles on hidden and wakes on focus. Grepping [Lifecycle] and [SkillsPlugin] "Window focused" alongside VM events should show the pause point.
That’s strong evidence of a lifecycle pause. Since the repro is switching sidebar tabs rather than unfocusing the whole app, it’d be useful to confirm whether hiding that session directly triggers its
running → idletransition.Followed up on the tab-switch question. Summary of what I tested today (Windows, packaged build, app focused throughout unless noted):
running → idle, no stall. So hiding a session tab alone does not pause it.Lifecycle transitions in the log are fast and normal (initializing → running → idle in ~14s per task); I don't see a session dropping running → idle from being hidden. So I'd refocus from "hidden tab pauses the session" to "two sessions doing local work at once contend for one VM." Happy to run a controlled two-active-session repro if thatّd help.
That rules out tab visibility as the cause. A two-active-session run with timestamps and MCP server logs should show whether the second call never arrives or gets held up while the VM handles the first one.