claude-code - 💡(How to fix) Fix [BUG] Cowork filesystem mount serves stale content and metadata; Claude Code on the same machine reads correctly [1 comments, 2 participants]

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?

Inside the Claude desktop app for Windows, the Cowork tab and the Claude Code tab return different and contradictory answers when reading the same file on the host Windows filesystem at the same moment in time. The Cowork tab returns a stale snapshot; the Claude Code tab returns the correct current state. This is the same app, same machine, same file, same user — only the tab differs.

Cowork's Read tool and bash stat both return the stale view, so the cache is metadata-inclusive. stat reports an old size and mtime alongside the old content, which means nothing inside the Cowork sandbox can detect the staleness from inside. There are no error messages; Reads succeed, stat succeeds, edits succeed — the returned values are just wrong.

The stale view is not drift that accumulates over the life of a session. It persists across: many tool calls within one Cowork session, a full uninstall and reinstall of the Claude desktop app (session state and the stale cache both survive the reinstall), and starting a brand-new Cowork session cold. A freshly-started Cowork session, on its very first Read of a file that has been modified externally for hours, still returns the pre-modification snapshot. The snapshot appears to be frozen at roughly the last moment Cowork itself wrote to that file.

Concrete numbers from one reproduction against C:\Users\Dave\katamari\wiki\concepts\RME.md, a 5.7 KB UTF-8 markdown file in an Obsidian vault. After the file's real on-disk state had been updated in Obsidian (adding a line TEST-MARKER-001 at the end, saved, Windows Explorer confirmed new Date modified):

• Cowork tab (existing session): 56 lines, Size 5756, Modify 2026-04-08 10:05:46, no marker.
• Cowork tab (brand-new session, cold first Read): 57 lines, Size 5756, Modify 2026-04-08 10:05:46, no marker. Same snapshot as the older session.
• Claude Code tab (same Claude desktop app, same machine, same moment): 59 lines, Size 5773, Modify 2026-04-08 13:07:18, marker present. Correct.

The 10:05:46 mtime corresponds to the last time the file was written from inside Cowork, during an earlier recovery session. The cache appears to have frozen at that write and has been inherited by every subsequent Cowork session on the machine, including sessions started after a full app reinstall.

From inside the Cowork sandbox, CLAUDECODE=1 and CLAUDE_CODE_HOST_PLATFORM=win32 are set in the environment, and claude --version returns 2.1.92 (Claude Code). So Cowork is literally Claude Code running inside a Linux VM (Ubuntu 22.04 on a 6.8 kernel) with the user's Windows folder exposed through a virtiofs share mounted at /mnt/.virtiofs-root/shared/c/Users/Dave/katamari and re-exposed to the sandbox via FUSE. The bug is not in the Read tool itself — the Read tool code is presumably identical between the two tabs — it is in the virtiofs-to-FUSE mount layer that Cowork uses and the Claude Code tab does not.

Practical impact. Any Cowork workflow that reads files which might have been modified externally — by the user in Obsidian, Word, Excel, VS Code, or File Explorer, or by the Claude Code tab, or by a prior Cowork session — is silently operating on stale data. We have hit this as (a) false positives in vault-wide lint sweeps, where a NUL-corruption scan reported a 48 KB file as 77% NULs when the actual on-disk file was 11 KB and clean (the stale cache was holding a partially-written intermediate state from an earlier sync), (b) destructive partial overwrites, where an edit built on a stale Read clobbered content that had been added to the file in the interim, and (c) inability to verify that Cowork's own edits actually landed on disk, because a post-edit Read from Cowork reads the write-through cache rather than the disk. For a user who switches between the Cowork and Claude Code tabs in the same app against the same folder, the divergence is actively confusing and quietly corrupts work.

What Should Happen?

The Cowork tab and the Claude Code tab should return identical answers when reading the same file at the same moment. External writes — from any application on Windows, including Obsidian, File Explorer, other editors, or the Claude Code tab of the same Claude desktop app — should be visible to Cowork within a bounded, documented interval (ideally immediately; at worst, within seconds of the host write completing). A brand-new Cowork session, started against a folder, should always see current on-disk state on its first Read, never a snapshot inherited from a previous session.

stat inside the Cowork sandbox should never report a size or mtime that disagrees with the actual on-disk file. Content caching is an understandable performance optimization; metadata lying is a correctness bug that defeats any attempt to detect staleness from inside the sandbox.

At minimum, if eager cache invalidation is infeasible for the virtiofs-to-FUSE bridge Cowork uses, there should be a user-facing or agent-facing affordance to explicitly drop the mount cache — a "refresh folder" button, a CLI command, a tool call, anything — and the caching behavior should be documented in the Cowork support docs so users can make informed decisions about which tab to use for which task. Ideally, the Cowork tab and the Claude Code tab would share a single filesystem bridge implementation, since the Claude Code tab demonstrably gets this right on the same machine at the same moment.

Error Messages/Logs

No error messages are produced. This is part of the problem: the failure mode is silent. Reads succeed, `stat` succeeds, edits succeed. The values returned are syntactically valid and internally consistent; they just do not match what is actually on disk.

The only diagnostic signal available from inside the Cowork sandbox is cross-referencing against an external source of truth — switching to the Claude Code tab of the same app, checking the file in Windows Explorer, or pasting content into chat by hand — which defeats the purpose of having a mounted workspace in the first place. A triage engineer investigating this will not find anything useful in Cowork's own logs; the interesting artifacts are the divergent outputs of `Read` and `stat` between the Cowork tab and the Claude Code tab, which are captured in the "What's Wrong?" section.

Steps to Reproduce

Prerequisites: Windows 11 (I'm on Home edition, but the bug is likely platform-agnostic). The Claude desktop app for Windows, latest version, with both a Cowork tab and a Claude Code tab available. Any folder on the Windows drive will do as a workspace; I'll call it C:\Users\<you>\test-folder\ below. No Obsidian or special tooling required — the bug reproduces on a plain two-line text file.

1. Create C:\Users\<you>\test-folder\test.md in Notepad. Put a single line in it: line one. Save and close Notepad.

2. In the Claude desktop app, open a Cowork session with test-folder as the selected workspace. Ask Cowork to read test.md using its Read tool. Expect line one. Also ask it to run stat test.md in bash and note the reported Size and Modify timestamp. Record both.

3. Without touching the Cowork tab, open test.md again in Notepad (or any external Windows editor). Add a second line: line two. Save and close. Verify in Windows Explorer that the file's Date modified and Size have updated.

4. Switch back to the Cowork tab in the Claude desktop app. Without making any write from Cowork's side, ask Cowork to Read test.md again and to run stat test.md again. Observed: Cowork returns only line one, and stat reports the pre-step-3 Size and Modify timestamp. Expected: Cowork returns both lines, and stat reflects the current on-disk values.

5. Close the Cowork session entirely and start a brand-new Cowork session from scratch against the same workspace folder. Ask it to Read test.md on its first tool call, cold, with no prior activity in the new session. Observed: still only line one, same stale stat. Expected: current post-edit state, since this session has never touched the file before.

6. In the same Claude desktop app, switch to the Claude Code tab against the same folder. Ask it to Read test.md and to run stat test.md. Observed: Claude Code returns both lines correctly and stat reports the current Size and Modify timestamp. This is the smoking gun: same app, same machine, same file, same moment, two tabs, two different answers.

7. (Optional, confirms the cache is metadata-inclusive rather than just content-level.) In the Cowork tab, try cat test.md, ls -la test.md, and find test-folder -newer /etc/hostname in bash. All three corroborate the stale view. There is no Cowork-side primitive I have found that can see through the cache.

The bug reproduces deterministically on my machine across every Cowork session I have tried, including sessions started after a full app uninstall and reinstall. The test file in my original investigation was a 5.7 KB markdown file in an Obsidian vault, but the reproduction steps above use a two-line plaintext file created in Notepad and reproduce identically, so there is no dependency on Obsidian, markdown, vault structure, or file size.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

1.1348.0.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

No response