[BUG] Cowork (Windows, cloud session): mapped network drive attached via folder picker works with file tools but is never mounted into the sandbox shell — breaks NAS workflows before Oct 6 removal of local-only mode

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?

Note: This issue was drafted by Claude (in a Cowork session) on behalf of the reporter, who runs a small business and is not a technical user. The reporter performed and confirmed every step below on his own machine; the technical wording and the reproduction steps come from Claude. He can rerun tests on request but may not be able to answer deep technical follow-up questions.

Environment

• Claude Desktop 2.9939.4 (Electron 44.4.3, Node 24.21.0), Windows x64
• Cowork session running in the cloud, desktop app linked as device bridge
• Workspace folder: Z:\Fiskalvertretung — a mapped SMB network drive on a company NAS, reached via VPN, attached through the folder picker (not a raw UNC path)

What happens
File tools over the device bridge work: listing the folder, staging files from it and committing files back to it all succeed. The shell does not: every device_bash call fails immediately with

None of the connected folders can be mounted into the workspace (e.g. network drives). Use device_stage_files / device_commit_files instead.

This was reproduced twice today, with a full quit of the desktop app (tray icon → Quit) between attempts and the VPN/drive connected before the app was started.

Why this matters
The reporter's company (a small EU customs and fiscal-representation consultancy) runs several Cowork skills that process document batches (30 to 700+ PDFs per run) directly on the NAS: Python scripts read the PDFs, write result files and update an Excel ledger. These skills are operated by staff with no IT background; the workflow is "attach folder, invoke skill". Until now this worked in local-only mode ("Only on this computer").

The announced Oct 6 change removes that option for new tasks. With the shell unable to reach the NAS, every one of these skills breaks. The stage/commit fallback (50 files per call, whole-file round trips) is neither practical for batch sizes of hundreds of PDFs nor something non-technical staff can be expected to operate. Moving the team to Claude Code is not an option.

Related
Looks like the same underlying gap as #96810 (mapped drive attached to VM but never exposed to the session shell), #54069 (UNC/mapped drives not supported in the Cowork shell) and #83847 (SMB share goes stale mid-session). #78671 recommends local-only mode as the workaround — which is exactly what is being removed.

What Should Happen?

Per the docs ("Desktop and filesystem access" → "Network drives on Windows"): a mapped drive that is reachable when the sandbox starts is mounted alongside local folders, and both file tools and shell commands work on it. We followed that order (VPN and drive connected, then app started, then folder attached) and expected device_bash to see the folder under $HOME/mnt/Fiskalvertretung.

Ask: either mount mapped network drives into the sandbox when they are reachable at start (as the docs already describe), or keep the local execution option ("Only on this computer") available for users who depend on network shares until that works.

Error Messages/Logs

device_bash → None of the connected folders can be mounted into the workspace (e.g. network drives). Use device_stage_files / device_commit_files instead.

get_device_info → { "platform": "win32", "arch": "x64", "appVersion": "2.9939.4", "electronVersion": "44.4.3", "nodeVersion": "24.21.0", "connectedFolders": ["Z:\\Fiskalvertretung"] }

device_list_dir Z:\Fiskalvertretung → OK (full listing returned)
device_stage_files Z:\Fiskalvertretung\Monatsstatus Intrastatmeldung 2026.09.xlsx → OK (41349 bytes, opens fine)
device_commit_files → Z:\Fiskalvertretung\Cowork\KW_Brueckentest.txt → OK (written: 1, rejected: 0)

Steps to Reproduce

1. On Windows, map an SMB share on a NAS to a drive letter (here Z:), reachable via VPN.
2. Fully quit Claude Desktop (tray icon → Quit, not just closing the window).
3. Connect the VPN and confirm Z: opens in Explorer.
4. Start Claude Desktop and wait about a minute.
5. Start a Cowork session (cloud mode) and attach Z:\<subfolder> via "+" → "Add folder".
6. Ask Claude to list the folder (works), read a file from it (works) and write a file into it (works).
7. Ask Claude to run any shell command inside the attached folder, e.g. ls $HOME/mnt/.
8. Every shell call fails with: None of the connected folders can be mounted into the workspace (e.g. network drives).

Repeated steps 2–8 twice with identical results.

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Claude Desktop 2.9939.4 (Cowork, Windows) — no CLI in use

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

• The reporter is filing this because Cowork local-only mode is being removed on Oct 6, 2026 and there is currently no working path for NAS-based workflows in cloud mode.
• Happy to run additional diagnostics on request (log files, further reproduction), with Claude's help in the session.