[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](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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\\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/ 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\\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\\Box\`.
3. Grant folder access to an ordinary local folder, e.g. `C:\Users\\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//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\\Downloads` | ordinary local disk | yes |
| `C:\Users\\Box\ClaudeCowork` | Box Drive | no |
| `C:\Users\\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\\Box` and opening Properties in File Explorer shows:

```
Type: Mounted Volume
Location: C:\Users\
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

```shell
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

Start by tracing how connected folders are handled between device_bash and the existing device_list_dir, device_stage_files, and device_commit_files routes, focusing on the mount-layer behavior for paths crossing a Windows mounted volume. Compare the successful ordinary-folder case with Box paths and determine whether the intended resolution is a filesystem fallback or clearer grant-time reporting. Done means the requested Box-path behavior is implemented and verified against the reproduction steps.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.