[BUG] [Desktop App 3P] Mapped network drive is attached to the VM but never exposed to the session shell (Windows)

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?

A mapped network drive (K:, a DFS-namespace share) is attached as a workspace folder through the folder picker. Per the documentation, a drive that is mapped and reachable when the sandbox starts should be mounted "alongside local folders" so that both file tools and shell commands work.

The logs show the drive meets that condition. On every VM boot the VM service adds the K share and HCS accepts it. On at least one boot the guest also mounted it. But the per-session mount step never binds the attached K: folder into the session. The agent's shell sees only outputs/uploads, and the session system prompt tags the folder as "network drive — bash cannot see this path". Re-mapping the drive or restarting doesn't change this.

Product: Claude Desktop 3P, agent/Cowork mode (third-party deployment) App version: 2.7032.0 (MSIX, Claude_2.7032.0.0_x64) Agent SDK in VM: 2.1.280 OS: Windows 11 Enterprise 10.0.26200 Date observed: 2026-09-21 through 2026-09-24 (ongoing). File tools work; shell/scripts against the attached network folder do not.

What Should Happen?

With K: mapped and reachable at VM start, and K:\Project\ attached as the session workspace folder, that folder should appear under /sessions/<id>/mnt/ and be usable from the shell tool.

/sessions/<id>/mnt/ contains only outputs and uploads (plus the read-only memory/skills/plugin mounts).
mount inside the session shows no mount for the K: folder.
The session system prompt describes the folder as a network drive that the shell can't see, so the app has decided not to expose it before the session starts.
File tools (Read/Write/Glob/Grep) on the same K: path work normally.

Error Messages/Logs

All excerpts come from the diagnostic log bundle (Claude-logs-2026-09-24T16-49-15-252Z). They are already redacted by the app. The full bundle can be provided on request.

1. The host VM service adds the K share on every boot, with no error (cowork-service.log)
2026/09/24 09:51:36.582662 [Server] Adding network-drive share K (unc len=28)
2026/09/24 09:51:36.582662 [VM] Plan9 share 'k' already configured identically (path=<network len=28> port=9910), skipping
2026/09/24 09:51:37.284925 [VM] Adding Plan9 share via HcsModifyComputeSystem: name=k path=<network len=28> port=9910 flags=0x10 hasToken=true
2026/09/24 09:51:37.284925 [HCS] HcsModifyComputeSystem returned: hr=0x0, lastErr=The operation completed successfully.
2026/09/24 09:51:39.692134 [VM] Guest mounted 1/1 fixed-drive Plan9 shares

The same sequence appears on the 2026-09-21, 09-22 and 09-23 boots. Note that the final line counts only fixed-drive shares. It doesn't report whether the network-drive share (k) was mounted in the guest.

2. The guest did mount k at VM level, at least on 2026-09-21 (coworkd-user.log, UTC)
2026/09/21 20:29:20 [hyperv] mounting Plan9 share "k" via vsock port 9910 at /mnt/<vol>/shared/k
2026/09/21 20:29:21 [hyperv] Plan9 share "k" mounted at /mnt/<vol>/shared/k (negotiated msize 262144)
2026/09/21 20:29:21 [hyperv] mounted 2/2 Plan9 shares

The guest log in the bundle ends on 2026-09-22, so guest-side state for the 09-23 and 09-24 boots isn't included.

3. The per-session binds never include the attached network folder (coworkd-user.log)

Even on the boot where k was mounted in the VM, the session got only these subpath mounts, all from share c:

[coworkd] mounting subpath for user <session> (uid=1001, mode=rw): /mnt/<vol>/shared/c/.../outputs -> /sessions/<session>/mnt/<vol>
[coworkd] mounting subpath for user <session> (uid=1001, mode=ro): /mnt/<vol>/shared/c/.../uploads -> ...
[coworkd] mounting subpath for user <session> (uid=1001, mode=ro): /mnt/<vol>/shared/c/.../memory/memory -> ...
[coworkd] mounting subpath for user <session> (uid=1001, mode=ro): /mnt/<vol>/shared/c/.../.claude/projects -> ...
[coworkd] mounting subpath for user <session> (uid=1001, mode=ro): /mnt/<vol>/shared/c/.../skills -> ...
[coworkd] mounting subpath for user <session> (uid=1001, mode=ro): /mnt/<vol>/shared/c/.../cowork_plugins/... -> ...

No subpath from /mnt/<vol>/shared/k/... is ever requested.

4. The app's network-drive snapshot can be read before the VM service is configured (cowork_vm_node.log)
2026-09-21 13:32:31 [warn] [vm-client] getNetworkDrives unavailable; keeping prior snapshot: Error: not configured: call 'configure' first
2026-09-23 15:02:38 [warn] [vm-client] getNetworkDrives unavailable; keeping prior snapshot: Error: not configured: call 'configure' first

We suspect a race. If the session-mount decision uses this snapshot and it's empty or stale, the folder would be classed as not mountable even though the share is attached moments later.

5. The session is configured with the folder under both its drive-letter and UNC forms (main.log, [HostLoop] sdkOptions)
additionalDirectories: [
  '<drv>:\\DNA_Projects\\DataScience',
  ...
  '<drv>:\\DNA_Projects\\DataScience',
  '\\\\<dfs-server>\\Teamdrives\\DNA_Projects\\DataScience',
]

The drive letter is being resolved to its UNC target, which is a DFS namespace path. The docs say raw UNC paths aren't supported. If the mount decision uses the resolved UNC path rather than the drive letter, that could explain why the folder is skipped.

6. Timing on 2026-09-24 (main.log / cowork_vm_node.log)
2026-09-24 09:51:34 setDraftSessionFolders: setting 0 folders for draft session
2026-09-24 09:51:36 [VM:start] Beginning startup ...
2026-09-24 09:51:41 [VM:start] Startup complete
2026-09-24 11:01:52 isFolderTrusted: <drv>:\DNA_Projects\DataScience\cowork -> true
2026-09-24 11:01:52 setDraftSessionFolders: setting 1 folders for draft session
2026-09-24 11:02:14 [startVM] VM already connected

The drive was mapped and the K share was attached at VM start. The folder itself was selected later, for a new session on the already-running VM. The docs imply that drive reachability at VM start is what matters, not when the folder is selected.

What has been ruled out
Drive not mapped or unreachable at VM start: ruled out. The host adds the K share on every boot and HCS returns hr=0x0.
VM not restarted since mapping: ruled out. The VM has been cold-started several times; logs show App quit, stopping VM followed by fresh boots.
Plan9 host-share outage from Windows KB5124008: ruled out. That was patched on 2026-09-18, and the C: share mounts and works normally.
Permissions on the folder: ruled out. File tools read and write the same path without issue.

Steps to Reproduce

Environment: Windows 11 Enterprise 10.0.26200, Claude Desktop 2.7032.0 (MSIX), agent SDK 2.1.280, agent/Cowork mode.

1. Map a network share to a drive letter (any SMB share works; ours is a DFS namespace path). In a normal, non-elevated PowerShell:

   net use K: \\<server>\<share> /persistent:yes

Confirm it opens in File Explorer.

1. Create a minimal test folder and file on the mapped drive:

   New-Item -ItemType Directory -Force K:\claude-mount-test
   Set-Content K:\claude-mount-test\hello.txt "hello from K:"

1. Fully quit Claude Desktop (system tray → Quit) so the VM stops. cowork_vm_node.log should show [VM:shutdown] App quit, stopping VM.

1. Relaunch Claude Desktop. Start a new agent-mode task and attach K:\claude-mount-test with the folder picker, choosing it through the K: drive letter (not via Network / UNC). Do this before sending the first message.

1. Send this prompt:

> Run these in the shell tool and show me the raw output: ls /sessions/*/mnt/, mount | grep /mnt, cat /sessions/*/mnt/claude-mount-test/hello.txt. Then read K:\claude-mount-test\hello.txt with the Read tool.

1. Observe the result:

• Expected (per the "Network drives on Windows" docs: mapped and reachable at sandbox start → file tools and shell commands both work): claude-mount-test appears under /sessions/<id>/mnt/ and cat prints hello from K:.
• Actual: /sessions/<id>/mnt/ contains only outputs and uploads, mount shows no entry for the folder, and cat fails with No such file or directory. The Read tool on the same K: path succeeds. The session system prompt already labels the folder "network drive — … bash cannot see this path" before any tool runs.

1. Collect logs (Help → Export logs) and check cowork-service.log. It shows the share is attached at VM start with no error:

   [Server] Adding network-drive share K (unc len=28)
   [VM] Adding Plan9 share via HcsModifyComputeSystem: name=k path=<network len=28> port=9910 flags=0x10 hasToken=true
   [HCS] HcsModifyComputeSystem returned: hr=0x0

However, coworkd-user.log never shows a mounting subpath for user ... line from /mnt/<vol>/shared/k/.... Only shared/c subpaths (outputs, uploads, memory, skills, plugins) are bound into the session.

Reproducibility: 100% across every VM boot from 2026-09-21 to 2026-09-24 (5+ cold starts).

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.280

Platform

AWS Bedrock

Operating System

Windows

Terminal/Shell

Other

Additional Information

Product: Claude Desktop 3P, agent/Cowork mode (third-party deployment) App version: 2.7032.0 (MSIX, Claude_2.7032.0.0_x64) Agent SDK in VM: 2.1.280 OS: Windows 11 Enterprise 10.0.26200 Date observed: 2026-09-21 through 2026-09-24 (ongoing) File tools work; shell/scripts against the attached network folder do not.