claude-code - 💡(How to fix) Fix [BUG] Cowork VM worker (vmwp.exe) overwrites host-side filesystem changes with stale VM-cached content on session startup

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Error Message

All consistent with the same vmwp.exe stale-cache-writeback mechanism observed in Procmon traces (see Error Messages/Logs section).

Error Messages/Logs

Fix Action

Fix / Workaround

  1. 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>).
  2. Close the Cowork session normally.
  3. 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, run git add -A && git commit -m 'host-side change'.
  4. Re-open the Cowork session on the same project (open the project in Claude desktop app → Cowork mode).
  5. Observe: the host-side change is reverted to whatever the VM had cached internally. git status --short from PowerShell shows the file as M (modified). The on-disk file now matches a pre-host-change state, not what was just committed.
  6. Recovery workaround: git show HEAD:<file> > <file> restores the host file to the committed state cleanly. For .git/index.lock orphan, Remove-Item -Force .git/index.lock from PowerShell. For .git/config line 17 truncation, manual text-editor repair.

Suggested Mitigation Paths (for Anthropic's evaluation)

  1. 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.
  2. 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.
  3. 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.

Code Example

FORENSIC EVIDENCESysinternals 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.
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • 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.lock recurrence at session-open (12+ sessions through K18). Lock is orphan-stale (no live process holds it); clears via PowerShell Remove-Item -Force.
  • .git/config line 17 truncation (5+ sessions). [branch "main"] merge key reverted to truncated state (\tmerge orphan 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:

  1. 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.
  2. The next Cowork session, on opening, should see the host-side state — not revert it to a stale VM-internal cache.
  3. 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.
  4. No .git/index.lock orphan-stale recurrence at session-open; no .git/config truncation; 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

  1. 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>).
  2. Close the Cowork session normally.
  3. 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, run git add -A && git commit -m 'host-side change'.
  4. Re-open the Cowork session on the same project (open the project in Claude desktop app → Cowork mode).
  5. Observe: the host-side change is reverted to whatever the VM had cached internally. git status --short from PowerShell shows the file as M (modified). The on-disk file now matches a pre-host-change state, not what was just committed.
  6. Recovery workaround: git show HEAD:<file> > <file> restores the host file to the committed state cleanly. For .git/index.lock orphan, Remove-Item -Force .git/index.lock from PowerShell. For .git/config line 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-Item for 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-parser PyPI 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)

  1. 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.
  2. 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.
  3. 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 evidence
  • scripts/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.

k18-trace.csv

analyze_procmon.py

k16-trace.csv k17-trace.csv

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [BUG] Cowork VM worker (vmwp.exe) overwrites host-side filesystem changes with stale VM-cached content on session startup