[BUG] Cowork (Windows): bash sandbox can't enumerate/delete files on CBFS-based virtual drive, though host-side Read/Write/Edit works

Describe the bug

On Cowork for Windows, when the selected working folder lives on a CBFS-based virtual drive created by Callback Technologies' CBFS Connect (this environment uses CBFS Connect 2022; Box Drive ships an older sibling from the same product line, cbfsconnect2017.sys), the two file-access paths inside Cowork behave inconsistently:

• The host-side file tools (Read / Write / Edit) work correctly. Reading an individual file by full path materializes it on demand, and writing a new file succeeds and is visible to the user on the real drive.
• The bash sandbox (Linux VM, virtiofs/Plan9 host-share) cannot see the same drive. Directory enumeration returns empty, sub-directories report "No such file or directory", and deletion (rm) cannot reach the files — including files that were just created successfully through the Write tool.

Net effect: Claude can read/write individual files if it already knows the exact path, but it cannot list directory contents or delete files on the virtual drive from the sandbox. This is the same class of incompatibility reported for OneDrive (#25293), Google Drive for Desktop (#55627), and Zoho WorkDrive (#41687), but with a distinct signature (per-file host-bridge access succeeds while sandbox enumeration/delete fails).

Environment

• OS: Windows
• Product: Claude Desktop — Cowork mode (Research Preview)
• Drive: B: — volume label "Shadow Virtual Drive" (Shadow Desktop), implemented via CBFS Connect 2022 (Callback Technologies) — the same product line as Box Drive, which ships the older cbfsconnect2017.sys
• Sandbox: Linux VM under Microsoft hypervisor (systemd-detect-virt → microsoft, hostname claude), folder shared via virtiofs/FUSE

To reproduce

1. Install a CBFS Connect-backed virtual drive (e.g. Shadow Desktop with CBFS Connect 2022, or Box Drive) so a drive like B: is presented by the CBFS Connect driver.
2. In Cowork, select a folder on that drive (e.g. B:\Desktop\Temp) as the working directory.
3. Ask Claude to (a) read a specific file by full path, (b) write a new file, (c) list the directory via the bash tool, and (d) delete a file via the bash tool.

Expected behaviour

All four operations should succeed, consistent with a local NTFS folder. In particular, directory listing and deletion from the sandbox should reflect the real contents of the drive.

Actual behaviour

• (a) Read by full path: works (host-side bridge materializes the file on demand).
• (b) Write new file: works (file appears on the real drive; confirmed visible from the user's WSL dir).
• (c) Bash directory listing: fails — the mount appears empty.
• (d) Bash deletion: fails — rm reports the file does not exist, even after delete permission is granted.

Diagnostics collected from the sandbox

Mount is a FUSE/virtiofs re-export of the host folder:

/mnt/.virtiofs-root/shared/b/Desktop on /sessions/<id>/mnt/Desktop type fuse
  (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)

Sandbox is a Hyper-V Linux VM, not the user's WSL distro:

$ systemd-detect-virt
microsoft
$ hostname
claude

Directory enumeration of the virtual drive returns empty from the sandbox, while the host dir shows ~60 entries:

$ ls -la /sessions/<id>/mnt/Desktop
total 8
drwx------ 2 ... .
drwxr-xr-x 8 ... ..
$ ls "/sessions/<id>/mnt/Desktop/Temp"
ls: cannot access '.../Temp': No such file or directory

A file written via the Write tool is readable back via the Read tool, but is not findable anywhere in the sandbox, and the user's WSL (drvfs mount of B: at /mnt/b) lists it normally:

# Read tool: B:\Desktop\Temp\cowork_write_test.txt  -> contents returned OK
$ find /sessions -iname "cowork_write_test*"
# (no output)

# User's WSL:
username@PC01:/mnt/b/Desktop/Temp$ dir
... cowork_write_test.txt ...

Likely root cause (analysis)

The host folder is re-exported to the sandbox over virtiofs/Plan9, which appears to assume a conventional local NTFS filesystem. CBFS Connect (like OneDrive's CldFlt and other callback/cloud-filter drivers) is a user-mode callback filesystem whose directory enumeration and on-demand materialization only fire when accessed through the normal Windows filesystem stack. WSL works because drvfs goes through that stack; the Cowork sandbox re-export does not, so the virtual drive's directory contents never propagate to the VM. The Read/Write/Edit tools work because they run host-side and hit the Windows API directly.

This suggests the fix belongs on the Cowork side: detect reparse/callback-type volumes (CBFS, CldFlt, etc.) and fall back to the host-side bridge for enumeration and deletion, rather than relying on the virtiofs re-export.

Related issues

• #25293 — Cowork Windows: sandbox-helper fails to mount host share (virtiofs/Plan9) with OneDrive-synced folders
• #55627 — Cowork cannot read Drive Desktop placeholder files
• #41687 — Cowork on Windows cannot write files to virtual network drives (Zoho WorkDrive)