[BUG] Cowork VM worker (vmwp.exe) overwrites host-side filesystem changes with stale VM-cached content on session startup
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?
In Cowork mode (research preview, desktop app, Windows 11), the Hyper-V VM worker hosting the Cowork sandbox writes VM-internal-cached copies of mounted-folder files back to the host filesystem at every VM startup. This silently reverts host-side filesystem changes that occurred between Cowork sessions, causing tracked-file drift in git-managed projects.
Across ~13 Cowork sessions on the same git-managed project, the following patterns have been observed:
.git/index.lockrecurrence at session-open (12+ sessions through K18). Lock is orphan-stale (no live process holds it); clears via PowerShellRemove-Item -Force..git/configline 17 truncation (5+ sessions).[branch "main"]merge key reverted to truncated state (\tmergeorphan with no= refs/heads/main); manual repair via text editor required to reach normal git operations.- Tracked-file content drift on multiple files (CLAUDE.md, .gitignore, multiple project markdown + HTML files). File reverts to older committed state, restored via
git show HEAD:<file> > <file>.
All consistent with the same vmwp.exe stale-cache-writeback mechanism observed in Procmon traces (see Error Messages/Logs section).
Note: this is a Cowork-mode bug, not a Claude Code CLI bug. The bug-report template asks for claude --version and terminal/shell details — those fields are filled with the closest analog values (desktop app version proxy, PowerShell). Filing on the anthropics/claude-code repo per precedent of existing Cowork-tagged issues (#50895, #49276, #27492, #48407).
What Should Happen?
Host-side filesystem changes made between Cowork sessions should persist when the next Cowork session opens. Specifically:
- After a Cowork session closes, host-side modifications to files in the mounted project folder (text edits, IDE saves, external git commits via PowerShell, etc.) should remain intact.
- The next Cowork session, on opening, should see the host-side state — not revert it to a stale VM-internal cache.
- The Hyper-V VM worker (vmwp.exe) should flush its internal file cache to host BEFORE shutdown (not write stale cache back on startup), OR use a host-pass-through filesystem mount that doesn't cache writes at the VM level.
- No
.git/index.lockorphan-stale recurrence at session-open; no.git/configtruncation; no tracked-file content reverts.
Error Messages/Logs
FORENSIC EVIDENCE — Sysinternals Process Monitor (Procmon) capture covering Cowork VM startup. Filter: path substring `wuld-ink\.git` (project's git internals directory). Captured 2,322 events in a ~60-second VM-startup window. 1,023 events from vmwp.exe (Hyper-V VM worker, PID 15688).
The critical mutation sequence at 20:11:12 on 2026-05-15 (mid-VM-startup):
20:11:12.362 vmwp.exe (PID 15688) SetEndOfFileInformationFile .gitignore (truncate)
20:11:12.404 vmwp.exe (PID 15688) WriteFile .gitignore (765 bytes at offset 0)
20:11:12.734 System (PID 4) WriteFile .gitignore (4096-byte page flush)
20:11:12.734 System (PID 4) SetEndOfFileInformationFile .gitignore
The 765-byte write reverted a recent commit's modification to `.gitignore`. The vmwp.exe write happens AFTER the host-side commit existed (verified via git reflog), indicating the VM held a stale snapshot from before the commit and wrote it back on next VM startup.
Attached CSV (k18-trace.csv, 2,322 events / ~600 KB) and analyze_procmon.py methodology script available on request.
Known library limitation discovered: procmon-parser 0.3.13 fails frame-alignment around the 9-9.66M event mark (deterministic across multiple captures). For multi-GB PMLs, only the first ~17-28% of events parse cleanly before the parser starts raising KeyError + ValueError on random offsets. Worth filing separately with procmon-parser maintainers. The parsed window is sufficient to demonstrate the vmwp.exe mechanism.
Steps to Reproduce
- Open a git-managed project in Cowork mode (any project with
.gitignore,CLAUDE.md, or any tracked file). Project must be on local filesystem (e.g.,C:\Users\<user>\Projects\<repo>). - Close the Cowork session normally.
- Modify a tracked file on the host side via any means while Cowork is closed (text editor, IDE, external commit via PowerShell, etc.). Example: append a line to
.gitignore, rungit add -A && git commit -m 'host-side change'. - Re-open the Cowork session on the same project (open the project in Claude desktop app → Cowork mode).
- Observe: the host-side change is reverted to whatever the VM had cached internally.
git status --shortfrom PowerShell shows the file asM(modified). The on-disk file now matches a pre-host-change state, not what was just committed. - Recovery workaround:
git show HEAD:<file> > <file>restores the host file to the committed state cleanly. For.git/index.lockorphan,Remove-Item -Force .git/index.lockfrom PowerShell. For.git/configline 17 truncation, manual text-editor repair.
The pattern recurs across ~13 sessions in a single project over multiple days. Sometimes it skips a session (clean open), but resumes the next session — not session-boundary deterministic, but persistent.
Claude Model
None
Is this a regression?
No, this never worked
Last Working Version
_No response_
Claude Code Version
N/A — Cowork mode in Claude desktop app, not Claude Code CLI
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
Operational Impact
- Not workflow-breaking — recovery is reliable via PowerShell
Remove-Itemfor lock orphans +git show HEAD:<file> > <file>for content drift + manual text-editor repair for config truncation. - Workflow cost: ~30-60 seconds per session-open for diagnostic + recovery cycle.
- Risk surface: uncommitted host-side changes between sessions are silently lost on next VM startup. The user must always commit before closing Cowork; deferred commits can be reverted invisibly.
Environment
- Claude desktop app, Cowork mode (research preview)
- Windows 11
- Project on local filesystem at
C:\Users\<user>\Projects\<repo>(not OneDrive) - Project is a Cloudflare Pages static-site repo with Git-deploy enabled
- Python 3.10 (for procmon-parser analysis)
- procmon-parser 0.3.13 (PyPI)
- Repo: github.com/alisendjsc-crypto/wuld-ink (public; can share state if useful)
Forensic Methodology
- Sysinternals Process Monitor (Procmon) with capture filter on
.git\directory - Python
procmon-parserPyPI package to stream binary PML logs - Custom analyze_procmon.py script (~200 lines) to filter by process_name + operation_type + time window
Multi-Session Investigation Trail
The Cowork project's CLAUDE.md tracks a ~7-experiment forensic narrowing process across ~13 sessions:
- Experiment 1 (Defender folder-scoped exclusion): NEGATIVE
- Experiment 2 (handle.exe path-arg trace): lock is orphan-stale; always-running daemon candidates ruled out
- Experiment 3-6 (multi-session pattern observation): isolated to out-of-band Windows-side process
- Experiment 7 (K19 Procmon trace analysis): vmwp.exe CONFIRMED as the I/O actor
Suggested Mitigation Paths (for Anthropic's evaluation)
- VM filesystem sync discipline: flush VM-internal file cache to host before VM shutdown; on startup, read from host (not cache) for any host-mounted folder.
- Mount mode change: use a host-pass-through filesystem mount (e.g., 9P, virtiofs) instead of cached-block-level mount where VM holds dirty pages.
- Operator-side workaround documentation: at minimum, document the recovery cycle in Cowork mode user guide so operators don't lose uncommitted work without knowing why.
Attachments Available (will provide if requested)
k18-trace.csv(2,322 events, ~600 KB) — the Procmon evidencescripts/analyze_procmon.py(~200 lines) — reproducible methodology, uses procmon-parser PyPI package- Subset of CLAUDE.md investigation block (Experiments 1-7) — the multi-session forensic narrowing trail
Note on this template's fit
This Claude Code bug-report template is structured for CLI bugs. Cowork mode is a Claude desktop app feature (research preview), not Claude Code CLI. Fields like Claude Code Version, Terminal/Shell, and Platform don't map cleanly. Filed here per precedent of existing Cowork-tagged issues (#50895, #49276, #27492, #48407). A dedicated Cowork bug template (or repo) would help future reporters.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗