[BUG] Cowork on Windows: folders under Box Drive fail to mount into the sandbox — Box is exposed as a mounted volume, not a directory

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?

[BUG] Cowork on Windows: folders under Box Drive fail to mount into the sandbox — Box is exposed as a mounted volume, not a directory

Summary

On Windows, connected folders that live under Box Drive (C:\Users\<user>\Box\...) are accepted by the folder-permission flow and appear in get_device_info.connectedFolders, but they never mount into the Linux sandbox. device_bash reports:

[Note: mnt/<folder> failed to mount and cannot be reached from this shell.
Those connected folders are still reachable via device_list_dir /
device_stage_files / device_commit_files, by their paths on this device.]

Ordinary local folders on the same machine, granted in the same session, mount normally. The failure tracks Box specifically, not the machine and not the individual folder.

The likely reason is visible in Windows itself: C:\Users\<user>\Box is not a directory on C:. Windows folder properties report Type: Mounted Volume. It is a reparse point into a separate volume served by Box's own filesystem driver. Anything that needs a normal directory handle on the same volume fails at that boundary.

This is the Windows counterpart of the cloud-storage mount failures reported on macOS (#62933 Dropbox, #24134 Google Drive, #52842 OneDrive), and it may be the same underlying defect as #19318 (cannot mount folders from external volumes) rather than a cloud-storage issue as such.

Environment

• Platform: win32, x64
• Device: Windows workstation, institutionally managed
• App version: 1.49585.0 (also reproduced on 1.46388.4)
• Electron 44.2.0, Node 24.20.0
• Sandbox kernel: Linux claude 6.8.0-136-generic #136~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC x86_64
• Box Drive installed and functioning normally in Windows

Steps to reproduce

1. On a Windows machine with Box Drive installed, start a Cowork session linked to that machine.
2. Grant folder access to a folder under Box, e.g. C:\Users\<user>\Box\<folder>.
3. Grant folder access to an ordinary local folder, e.g. C:\Users\<user>\Downloads.
4. Run device_bash with ls -1 "$HOME/mnt/".

Expected

Both granted folders appear under $HOME/mnt/ and are usable from the shell.

Actual

Only the non-Box folder appears. Every Box folder fails to mount.

$ ls -1 "$HOME/mnt/"
Downloads

[Note: mnt/ClaudeCowork, mnt/DesktopTemp failed to mount and cannot be
reached from this shell. ...]

Mount table shows the working folder attached over FUSE, with no entry for either Box folder:

$ mount | grep mnt
/proc/self/fd/3 on /sessions/<id>/mnt/Downloads type fuse
  (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)

Evidence that this is Box-specific, not folder-specific

Three folders were granted in one session:

| Folder | Location | Mounts? |
|---|---|---|
| C:\Users\<user>\Downloads | ordinary local disk | yes |
| C:\Users\<user>\Box\ClaudeCowork | Box Drive | no |
| C:\Users\<user>\Box\DesktopTemp | Box Drive | no |

Two unrelated Box folders, with different names, contents and sizes, both fail; a non-Box folder granted in the same session succeeds. This rules out explanations tied to any one folder — size, file count, name, or contents.

Evidence from Windows about what the Box path actually is

Right-clicking C:\Users\<user>\Box and opening Properties in File Explorer shows:

Type:     Mounted Volume
Location: C:\Users\<user>
Target:   Box

The reported size of that volume is roughly 946 GB, on a machine with about 612 GB of free disk. The volume therefore cannot be a materialized directory tree on C:; it is a virtual volume whose contents are served on demand by Box's driver.

This is consistent with what is known publicly: Box's actual data lives in a database under AppData\Local\Box, and the mechanism is undocumented. The same barrier blocks Box folders from being mounted into WSL (microsoft/WSL#4310, mount -t drvfs fails with "wrong fs type, bad superblock") and from being bind-mounted into Docker Desktop containers on Windows (Docker forum thread "Mount on Box Drive", where direct mounting produced I/O errors and a mapped network share returned an empty directory). Box support states that WSL2 is not supported.

Ruled out: local caching does not help

Box's "Make Available Offline" pins a folder's contents to local disk. Box marks a pinned folder with a green check badge in File Explorer and an online-only folder with a blue cloud badge.

Both folders that fail to mount carry the green badge. ClaudeCowork and DesktopTemp are each pinned to local disk, and each still fails to mount. Their context menu offers only the reverse toggle, "Make Available Online Only", confirming the state.

For completeness, the Box root on this machine is a mixture: of 28 top-level items, 10 folders are pinned locally (green) and 18 items are online-only (blue cloud), the latter mostly folders shared by collaborators. The two failing folders are both from the pinned group, so the mixture is not itself implicated.

Having the bytes present on local disk is therefore not sufficient; the volume boundary is what blocks the mount.

This matters for triage, because "ask the user to download the files locally" is the standard advice on the macOS issues and does not fix this case.

Notable: the other file routes work fine

device_list_dir, device_stage_files and device_commit_files all work correctly against the same Box paths. Directory listings return real entries with sizes and modification times, staging a file out of Box succeeds, and committing a file back into Box succeeds. Windows-side shells can also enter the folder normally — File Explorer's "Open in Terminal" works on it.

So both the desktop app's ordinary file APIs and Windows' own shells handle Box fine. Only the step that attaches the folder to the Linux sandbox fails.

Probable cause and suggested fix

The mount layer appears to require a directory it can attach directly, and fails when the path crosses a reparse point into a foreign volume. Since device_list_dir, device_stage_files and device_commit_files already read and write these same paths successfully through ordinary file APIs, the natural fix is for the FUSE backend to fall back to that path rather than requiring a mountable directory handle.

If that is not feasible, a clear error message would still help. At present the notice appears only in device_bash output, so a user who never runs a shell command has no idea the folder is only half-connected. Surfacing it when the folder is granted — "this folder is on Box Drive and cannot be attached to the sandbox; reading and writing files will still work" — would set expectations correctly.

Impact

Moderate, not fatal. Users who keep working files in Box — common in universities and enterprises with Box site licenses — lose the ability to run shell commands, scripts, searches or in-place edits across those files. Work must be done by copying files into the cloud container and copying results back, which is slower and creates two copies of each file that can drift apart.

Related issues

• #19318 — cannot mount folders from external volumes (possibly the same defect)
• #62933 — Cowork can't mount paths inside Dropbox on macOS
• #24134 — Google Drive for Desktop mirrored/streaming folder fails to mount
• #52842 — mount error when ~/Documents is a symlink to OneDrive

What Should Happen?

Claude should be able to mount the local CoWork dir

Error Messages/Logs

see above

Steps to Reproduce

see above

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.266 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

see above