**[BUG] Cowork locks up after ~5 min — EventEmitter memory leak (MaxListenersExceededWarning) accumulates per session, Electron renderer freezes**

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/65887
2. https://github.com/anthropics/claude-code/issues/59967
3. https://github.com/anthropics/claude-code/issues/66849

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Thanks for reporting this — I've seen similar memory/resource issues across multi-agent setups and there are a few things worth checking before it gets lost in triage.

Quick diagnostic matrix (3 things to try right now):

1. Session isolation — if the tool spawns child processes (sub-agents, MCP servers), check whether those are being reaped properly. Run ps aux | grep -i node during a session and after exit. Zombie processes after session close = child-process leak.

1. Token context growth — long sessions accumulate context. Monitor memory with ps -o pid,rss,vsz,comm -p $(pgrep -f claude) at 0 min, 10 min, 30 min. If RSS grows linearly without plateauing, context retention is the leak.

1. MCP server lifecycle — if you're using MCP tools, the transport layer (stdio/SSE) can leave orphaned connections. Check lsof -p <pid> for dangling TCP/FIFO handles after tool calls complete.

Hardening playbook I use for production AI-coding setups:

• Set a session time-limit alarm (background timeout 30m ... or equivalent)
• Audit child-process lifecycle: every fork must have a corresponding reap
• Monitor per-session memory ceiling and auto-restart if exceeded

Happy to share a checklist if this sounds like what you're hitting. This class of issue usually maps to session lifecycle management gaps more than a code bug, and the fix is operational before it's a patch.

Thanks for the suggestions. A few clarifications based on the logs and further testing:

The leak is in the Electron renderer, not child processes or MCP servers.

The MaxListenersExceededWarning is in claude.ai-web.log, not in any subprocess:

MaxListenersExceededWarning: Possible EventEmitter memory leak detected.
11 $eipc_message$...$_AutoUpdater_$_updaterState_$store$_update listeners added.

All 9 MCP servers are connected and healthy per main.log at time of lockup. The issue appears to be AutoUpdater event listeners not being removed when Cowork sessions are torn down — classic on() without a corresponding off() or once().

Root cause appears to be long-running sessions with large context windows.

I was maintaining a single Cowork session across multiple relaunches of Claude Desktop while working on a coding project. The lockup started occurring towards the end of a long session, suggesting context window size is a contributing factor. Each time Claude Desktop was relaunched and reconnected to the existing session, AutoUpdater listeners were re-registered on top of the existing ones without cleanup. The combination of accumulated context and repeated reconnection events appears to drive the listener count past the threshold and freeze the renderer.

Starting a new conversation rather than relaunching resolves it — a fresh session starts with a clean listener slate. This is completely non-obvious; nothing in the UI indicates that relaunch vs. new conversation makes any difference to the underlying session state, and the natural instinct when an app freezes is to relaunch it.

A notable UI signal: after relaunching Claude Desktop, the previous Cowork session consistently showed a blue dot indicator, suggesting the session was still considered active rather than having been properly torn down. This aligns with the listener accumulation pattern — if the session is never fully closed, reconnecting on relaunch adds listeners on top of an already-live session rather than initializing a clean one. The blue dot may be a reliable user-visible indicator of this condition. CoworkVMService remaining running after Claude Desktop exits is the likely mechanism keeping the session alive.

Secondary issue: CoworkVMService race condition

Separate from the memory leak, CoworkVMService is set to StartType=Automatic but consistently stops before Claude Desktop launches. Claude Desktop attempts to connect to \\.\pipe\cowork-vm-service before the service is ready, causing repeated ENOENT errors. Manual Start-Service CoworkVMService resolves it. sc.exe config CoworkVMService start= delayed-auto returns Access Denied even as local admin — the MSIX service descriptor locks out configuration changes, so there's no supported way to set delayed autostart.

Suggested fixes:

1. Remove/deregister AutoUpdater listeners on session teardown
2. Skip re-registration on relaunch if listeners are already attached
3. Stop CoworkVMService when Claude Desktop exits to ensure clean session teardown
4. Auto-compact or warn when context window approaches limits in long Cowork sessions
5. UI guidance — when Cowork fails, suggest "start a new conversation" rather than just restarting the app
6. Allow delayed autostart configuration on CoworkVMService, or set it by default in the MSIX installer

Update, this issue is easily reproducable on a fresh session simply by telling cowork to ingest some files in a folder and before it asks for permission, click off the app and click any other app. I see the permissions request pop up in Cowork, but I cannot click back on the Cowork app as it freezes. When this happens, these errors pop up in the logs

2026-06-13 16:22:05 [warn] Blocked permission check {
permission: 'background-sync',
2026-06-13 16:22:05 [warn] Blocked permission check {
permission: 'background-sync',
2026-06-13 16:25:40 [warn] Blocked permission check {
permission: 'background-sync',
2026-06-13 16:25:40 [warn] Blocked permission check {
permission: 'background-sync',
2026-06-13 16:27:43 [warn] [HostLoop] cli.js stderr: Permission deny rule "JavaScript" matches no known tool — check for typos.
2026-06-13 16:27:59 [info] Emitted tool permission request c336d0fe-9b0d-4ba6-bfa5-6594c3ec0c78 for mcp__cowork__request_cowork_directory in session
local_60511dfd-6ceb-4020-9710-124923c2852a

I believe the background-sync errors are begning, but the JavaScript permission deny seems like a possible cause of the freeze.

Checked all user-side config locations for a misconfigured deny rule:

C:\Users\<user>\.claude\settings.json — only contains autoUpdatesChannel and theme, no permission rules
%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\cowork-enabled-cli-ops.json — only contains ownerAccountId
%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalState — empty, no VM config files present

No user-configured deny rules exist anywhere in the Windows-side config. The warning originates from cli.js inside the VM itself, tagged as [HostLoop] cli.js stderr, meaning it is emitted by the VM process during boot — not by anything the user can configure or modify.

#####

If I stay in the Cowork window and click to allow file access, this is what is logged:

2026-06-13 16:43:51 [warn] [HostLoop] cli.js stderr: Permission deny rule "JavaScript" matches no known tool — check for typos.
2026-06-13 16:43:56 [info] Emitted tool permission request 058a39fd-ee3b-4f78-a095-5cc237856e01 for mcp__cowork__request_cowork_directory in session
local_60511dfd-6ceb-4020-9710-124923c2852a
2026-06-13 16:45:20 [warn] Blocked permission check {
permission: 'background-sync',
2026-06-13 16:45:20 [warn] Blocked permission check {
permission: 'background-sync',
2026-06-13 16:45:56 [warn] [HostLoop] cli.js stderr: Permission deny rule "JavaScript" matches no known tool — check for typos.
2026-06-13 16:46:08 [info] Emitted tool permission request 759a16b9-1260-462b-86c0-ba2b886c30f2 for mcp__cowork__request_cowork_directory in session
local_60511dfd-6ceb-4020-9710-124923c2852a
2026-06-13 16:46:09 [info] LocalAgentModeSessions.respondToToolPermission: requestId=759a16b9-1260-462b-86c0-ba2b886c30f2, decision=once, hasUpdatedInput=true
2026-06-13 16:46:09 [info] Received permission response for 759a16b9-1260-462b-86c0-ba2b886c30f2: once (tool: mcp__cowork__request_cowork_directory)

You can see the LocalAgentModeSessions.respondToToolPermission which doesn't happen when the windows freezes when Claude isn't the focused window.

Update — root cause identified and resolved

After extended debugging I can confirm the MaxListenersExceededWarning is a symptom, not the root cause. The actual cause is Windows Fast Startup leaving an orphaned Hyper-V VM process across shutdown/boot cycles.

---

What was happening

Windows Fast Startup (HiberbootEnabled = 1) hibernates the kernel session on shutdown rather than terminating it. The Hyper-V VM process survives the hibernate/resume cycle as an orphaned instance. On the next Claude Desktop launch, HCS contention from the stale VM manifests as Electron main-process event-loop stalls, which degrade the UI thread enough that:

1. CoworkVMService drops mid-session
2. Tool permission prompts (mcp__cowork__request_cowork_directory, AskUserQuestion) are emitted but never render — session blocks indefinitely
3. The EventEmitter leak accumulates as the renderer keeps trying to reattach listeners to a VM that is no longer responding

Log evidence captured during an active freeze:

2026-06-12 14:22:21 [warn] [event-loop-stall] main process blocked for 604ms (total 1, cumulative 604ms, rss 305MB)
2026-06-12 14:22:25 [warn] [event-loop-stall] main process blocked for 546ms (total 2, cumulative 1150ms, rss 304MB)
2026-06-12 14:22:33 [warn] [event-loop-stall] main process blocked for 976ms (total 3, cumulative 2126ms, rss 309MB)
2026-06-12 14:27:56 [warn] [HostLoop] VM boot failed; bash proxy unavailable: VM service not running. The service failed to start.

The stalls precede the VM drop every time. No stalls = no drop.

---

Fix

Disable Fast Startup:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Power" /v HiberbootEnabled /t REG_DWORD /d 0 /f

Follow with a full cold shutdown and power-on (not restart — restart also bypasses Fast Startup and won't clear existing hibernated Hyper-V state).

After the cold boot: no event-loop stalls, CoworkVMService remains stable across sessions, permission prompts render and are clickable even when Claude is not the focused window.

---

Secondary issues confirmed during investigation

• CoworkVMService ships with no FailureActions configured and cannot have them set via sc.exe failure (Access Denied on MSIX services). A scheduled task watchdog at 5-minute intervals is the only available auto-recovery mechanism until the MSIX manifest is updated.
• Fast Startup is enabled by default on most Windows 11 OEM machines and is not checked or warned against by the Cowork preflight. This is likely affecting a large proportion of Windows users hitting the ~5 minute hang pattern.

Relates to #36590, #59794, #43534.