Cowork VM sandbox RPC desync corrupts host app installation ACLs, forcing repeated full uninstall/reinstall (Windows)

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?

During a Claude Code session using the Claude Browser tool (mcp__Claude_Browser__*) to automate the Cloudflare dashboard (dash.cloudflare.com, OneTrust cookie-consent widget with a large/deeply-nested accessibility tree), the persistent RPC connection between claude.exe and the cowork-svc.exe Windows sandbox service dropped 3 times in under an hour (2026-07-31, 00:28, 00:54, 01:16 local time). Unlike the many other "message too large" / EOF disconnects visible in the same service log going back to June (which normally self-heal via a silent reconnect), these 3 disconnects each caused Windows to detect broken ACL permissions on the app's own install folder (C:\Program Files\WindowsApps\Claude_1.24012.9.0_x64__pzs8sxrjxfjjc), attempt an automatic repair, fail validation, and then fully uninstall + reinstall the entire app package (a freshly-staged .msix each time). From the user's perspective this looked exactly like "the app crashed and uninstalled itself," requiring a fresh install to recover -- 3 times in one working session.

What Should Happen?

An RPC framing desync between claude.exe and the cowork-svc.exe VM sandbox service should, at most, cause a clean session restart/silent reconnect (as happens in every other occurrence of this same desync visible in the logs since June). It should never cascade into corrupting the app's own install-folder ACLs or trigger a full uninstall/reinstall of the app package.

Error Messages/Logs

Session transcript (9e47fc97-05e4-49d5-b97d-48fe8703cda8.jsonl), last event at 2026-07-31 01:16:39.886 local -- a mcp__Claude_Browser__computer click (left_click, ref_9, "Allow All" on the OneTrust cookie banner) returns "ref map not initialized; call read_page first".

C:\ProgramData\Claude\Logs\cowork-service.log, same moment:
2026/07/31 01:16:40.246482 [Server] Persistent RPC: connection ended: failed to read length: EOF
-- within 1 second of the browser tool error above.

Same pattern for the two earlier disconnects in the same continuous work session (spanning two transcript files due to a mid-session restart): 2026-07-31 00:28:31 and 00:54:49.

Each of the 3 disconnects was followed (per Microsoft-Windows-AppXDeploymentServer/Operational log, event IDs 603/607/649) by:
1. RegisterByPackageFullName with RepairAppRegistrationOption -- "Trying to repair ACLs for ...Claude_1.24012.9.0_x64__pzs8sxrjxfjjc" -> "ACLs repaired successfully... Register next time should succeed."
2. A full Remove operation (PreserveApplicationData, then PreserveApplicationData,RemoveForAllUsers)
3. A full Add operation reinstalling a freshly-staged .msix (different filename each time: Claude-1010529330.msix, Claude-196803593.msix, Claude-3080732764.msix -- same version 1.24012.9.0)

sfc /scannow was run afterward and found unrelated corruption (one Bluetooth driver, bthmodem.sys) -- ruling out general OS file corruption as the cause. No malware detected (Windows Defender), no disk space issue (500+ GB free), no crash dumps or WER reports generated for claude.exe itself.

Steps to Reproduce

1. On Windows, open a Claude Code Desktop session and use the Claude Browser tool (mcp__Claude_Browser__*) to navigate to a page with a large/deeply-nested accessibility tree -- in this case dash.cloudflare.com, which shows a OneTrust cookie-consent widget with hundreds of nested elements.
2. Interact with the page repeatedly via computer/read_page calls over an extended session (worked continuously ~50+ minutes here, spanning a mid-session restart into a second transcript file).
3. Watch C:\ProgramData\Claude\Logs\cowork-service.log for "Persistent RPC: connection ended: failed to read length: EOF" or "message too large: NNNN bytes" -- this occurs periodically and normally self-heals.
4. On this occasion, 3 of these disconnects (within the same ~50 minute session) instead triggered a Windows AppX repair-then-reinstall cycle, visible in Event Viewer > Applications and Services Logs > Microsoft-Windows-AppXDeploymentServer/Operational, and in Event Viewer > Windows Logs > System (service install/start-type-changed events for "Claude", IDs 7045/7040).
5. Each cycle ends with the whole Claude desktop app being fully uninstalled and reinstalled (same version, freshly re-staged .msix), which surfaces to the user as the app "closing/uninstalling itself" mid-session.

Note: I have not yet found a way to reliably force the desync to escalate into ACL corruption on demand -- it happened 3/3 times during this specific real session but the same EOF pattern has occurred many other times historically (per the log, since June) without this escalation.

Claude Model

Other

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.219 (Claude Code Desktop app, Windows)

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

Claude Model detail: claude-haiku-4-5-20251001 (the dropdown above doesn't list Haiku, selected "Other").

App/component: Claude Code Desktop app for Windows (not CLI/terminal-only) -- the crash involves cowork-svc.exe, a Windows service (Hyper-V/HCS-based sandbox VM) bundled with the desktop app, and the mcp__Claude_Browser__* tool (in-app Browser pane).

App package: Claude_1.24012.9.0_x64__pzs8sxrjxfjjc (MSIX)

Suspected root cause: The RPC framing desync ("message too large: ~2GB" / "failed to read length: EOF") between claude.exe and cowork-svc.exe is a known, usually-benign, recurring pattern visible in this environment's logs since June. It appears to be triggered or exacerbated by large/complex accessibility-tree payloads from Browser-tool read_page/computer calls against pages with heavy widget nesting. On this occasion the desync escalated beyond a silent reconnect and left the app's own install-folder ACLs in a state Windows considered broken, triggering a repair-then-reinstall cascade 3 times in ~50 minutes.

Suggested fix direction:

• Harden the RPC framing/length-prefix handling in cowork-svc.exe so a desync never cascades into ACL/package-registration corruption -- at most it should cause a clean session restart, matching the many other historical EOF disconnects that self-heal silently.
• Cap or chunk large read_page/computer accessibility-tree payloads from the Browser tool before they cross the VM RPC boundary.

Ran sfc /scannow afterward: found and fixed one unrelated corrupt file (bthmodem.sys, a Bluetooth driver) -- ruling out general OS file corruption as the cause. No malware detected, 500+ GB free disk space, no crash dumps/WER reports generated for claude.exe.