Windows: folders connected via the desktop UI never reach the running Cowork session (get_device_info reports them missing)

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?

On Windows, folders connected through the desktop app never become visible to the running Cowork session. get_device_info keeps returning only the folder the agent had granted itself earlier via device_request_folder_access. Nothing errors, and nothing warns either the user or the agent that the session has no access.

The user attempted this three times over the course of one session: once through desktop app settings, and twice with the Add folder button during the live session. After every attempt:

"connectedFolders": ["C:\\Users\\User\\Downloads"]

This appears to be the same defect as #86647, which is currently filed as macOS-only. Two things this report adds:

1. It reproduces on Windows (app 1.37937.3, Electron 42.10.0, Node 24.18.1).
2. The workaround documented in #86647 does not work here. Clicking Add folder mid-session is the fix reported in that issue; on Windows it changed nothing.

Worth noting: device_request_folder_access — the agent-initiated grant — worked correctly on the same machine, in the same session, moments before and after the failed UI attempts. So the underlying grant mechanism is fine. It is specifically the UI-initiated path that fails to propagate.

Why this matters beyond a misplaced file

The connected folder is the agent's working memory within a session and between sessions. When it silently isn't there, the agent cannot:

• Read back its own outputs. In this session the agent generated a diagnostic script, asked the user to run it, and then needed to read the resulting report. That only worked because the file happened to land in Downloads — the one folder the agent had granted itself. Had it landed in the folder the user actually configured, the agent would have been blind to a file it had just asked the user to create.
• Consult prior work. The user keeps a folder used across several machines holding earlier reports, notes and end-of-session write-ups. None of it was reachable, so context that should have carried between sessions simply did not exist.
• Keep its own files tidy. Everything produced had to go to Downloads, directly against an explicit instruction from the user that Downloads is a landing spot only. The agent could not then correct this, because the Windows bridge exposes no shell and no move or delete capability — so the user had to clean up by hand after being told the agent would handle it.

The user's own framing, which is fair: being unable to find the folder they set up compromises the agent's ability to deliver reliable, consistent quality, because it can neither read its own reports nor work through its own files.

The silence is a large part of the harm. The UI showed the folders as connected. The user reasonably concluded they had configured something wrong, and repeated the setup several times before the agent thought to check get_device_info and discovered the mismatch.

What Should Happen?

A folder connected through the desktop app UI should appear in the session's connectedFolders and be readable and writable by the agent — on Windows as on macOS.

If a grant genuinely cannot be applied to an already-running session, the session should be told, and the agent should be able to surface that to the user, rather than both sides silently believing the folder is connected.

Error Messages/Logs

There is no error output — that is the core of the problem. The only observable signal is the mismatch between the UI and the session state.

get_device_info, after the user connected additional folders through the desktop app:

{
  "platform": "win32",
  "arch": "x64",
  "appVersion": "1.37937.3",
  "electronVersion": "42.10.0",
  "nodeVersion": "24.18.1",
  "deviceName": "command-centre",
  "connectedFolders": [
    "C:\\Users\\User\\Downloads"
  ],
  "homeDirectories": [
    { "name": "ansel" }, { "name": "Contacts" }, { "name": "Downloads" },
    { "name": "Favorites" }, { "name": "Links" }, { "name": "Saved Games" },
    { "name": "Searches" }
  ]
}

device_list_dir on a path the UI reported as connected:

C:\Users\User\OneDrive is not inside a folder connected to Cowork on this device.
Call device_request_folder_access with the folder you need (the user is asked to approve);
if it can't be granted that way, ask the user to connect that folder.

Steps to Reproduce

On Windows, with a Cowork session linked to the desktop app:

1. Start a session with no folders connected. Call get_device_info — connectedFolders is empty.
2. Have the agent call device_request_folder_access on a plain local path (e.g. C:\Users\<user>\Downloads) and approve the prompt. Call get_device_info — the folder appears immediately. This path works.
3. Now connect one or more additional folders through desktop app Settings. Call get_device_info — the new folders are absent.
4. Connect a folder using the Add folder button while the session is live (the workaround given in #86647). Call get_device_info — still absent.
5. Call device_list_dir on one of those folders — it fails with "is not inside a folder connected to Cowork on this device", despite the UI showing it as connected.

The mismatch persists for the remainder of the session. Only step 2 — the agent-initiated grant — ever produces a usable folder.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude desktop app 1.37937.3 (Cowork) — not the claude-code CLI

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Related, possibly a separate issue — OneDrive folders cannot be added at all on Windows.

I have kept this report to the single defect above, but the two were hit together and may share a root cause. The user's cross-machine working folder lives in OneDrive, and the folder picker refused to add it. #44710 documents this for macOS (symlink resolution into ~/Library) and is closed; there is no Windows equivalent on file, where the mechanism would differ — OneDrive folders on Windows are reparse points backed by the cloud filesystem provider, not symlinks.

This matters more on Windows than the macOS ticket implies, since OneDrive is the default document location on a large share of Windows installs. "Put your working folder in OneDrive" is the normal configuration there, not an edge case. Combined with #62140 (silent truncation of Files-On-Demand placeholders, still open), cloud-synced folders on Windows are currently either unusable or unsafe. Happy to file that separately if it would be more useful.

Suggested fixes for the issue reported here:

1. Propagate UI folder grants to running sessions on Windows — or, if that is not possible, surface an explicit error so the agent can tell the user rather than both sides silently assuming access.
2. Make the folder picker give a real refusal reason (cloud-backed path, protected location) instead of failing silently.
3. Consider exposing move/delete on the Windows bridge, or documenting their absence. An agent that can write files into a user's folder but cannot tidy them up afterwards puts the user in the position of cleaning up after it.

Environment: Windows, win32 x64, desktop app 1.37937.3, Electron 42.10.0, Node 24.18.1. Observed 2026-08-27.