claude-code - 💡(How to fix) Fix Cowork: launch virtiofsd with cache=none on workspace mounts to fix stale .git/index.lock [1 comments, 2 participants]

Problem

Cowork's workspace folder is shared into the sandbox VM via virtiofs with what appears to be cache=always (or auto) and writeback enabled. This causes a well-known virtiofs cache-coherency bug: when a file is deleted on the host, the guest page cache keeps the dentry pinned, so the guest still 'sees' the file on subsequent stat/open calls.

In practice this breaks all git write operations on a mounted repo. A stale .git/index.lock from a prior background git process remains visible inside the VM even after the host has removed it, so every git add / git commit fails with:

fatal: Unable to create '.git/index.lock': File exists

Attempting to rm or unlink the lockfile from inside the VM fails with Operation not permitted, because the file no longer exists on the host — only in the guest cache.

Related upstream reports:

• kata-containers/runtime#2770 — virtio-fs cache prevents host deletes from propagating
• kata-containers/runtime#1902 — same root cause
• kata-containers/kata-containers#691 — upstream moved virtiofsd default to cache=none for exactly this reason
• anthropics/claude-code#28890 — VirtioFS mount goes stale, breaks workspace sessions
• anthropics/claude-code#11005 — stale .git/index.lock blocks git commands

Current workaround (in our project's CLAUDE.md)

Every agent must clone the mounted repo to /tmp (local VM disk, not virtiofs), do all git work there, push, then cp files back. This works but is slow, error-prone, and requires every agent prompt to know about it.

Proposed fix

Launch virtiofsd for Cowork workspace mounts with one of:

1. --cache=none (preferred — matches kata-containers default, fully fixes the bug, only costs read throughput on bulk file reads which is irrelevant for code repos), or
2. --cache=auto --writeback=no + guest mount option noauto_cache (keeps read perf, forces metadata revalidation on lookup — should also fix lockfile coherency).

Either change is host-side only; nothing inside the sandbox can work around this properly.

Repro

1. Open a Cowork session with a git repo in the selected workspace folder.
2. Run any background-y git operation that creates .git/index.lock and is killed before cleanup.
3. From the host, rm .git/index.lock.
4. Inside the sandbox, ls .git/index.lock — file is still visible. git commit fails. rm fails with EPERM.

Impact

Every agent doing git work on a Cowork-mounted repo has to carry a /tmp clone workaround in its prompt. Removing this would simplify dozens of agent prompts and remove a whole class of silent failures.