[BUG] Cowork on Windows: mid-session folder grant refuses the home directory that the task-start picker offers

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, the Cowork task-start folder picker offers C:\Users\<user> as a selectable working folder, and it is also present in Settings under Trusted Cowork folders.

Mid-session, a request_cowork_directory call for that same path is refused by a policy guard before it ever reaches the user. No permission dialog is shown. The tool returns:

That directory is Cowork's internal session storage. Tool-result files are already readable via the existing rules — read them directly. Other files there (transcripts, session state) are intentionally not accessible. Request a project folder on the user's machine instead.

The guard fires because Cowork's session storage lives at C:\Users\<user>\AppData\Roaming\Claude, which is inside the home directory. The guard appears to reject the entire home directory rather than just that subtree.

The result is that the same path is grantable at task start and ungrantable mid-task. The grant is available exactly when it is not needed and unavailable the moment it is.

This is not a theoretical problem. On Windows, a user whose work spans multiple trees under their home directory (for example %USERPROFILE%\My Drive\... and %USERPROFILE%\OneDrive\...) has the home directory as the only single path covering all of them. That is the one path the mid-task guard refuses.

What Should Happen?

The two surfaces should agree.

Either:

1. Granting the home directory is unsafe because session storage lives under it, in which case the task-start folder picker and the Trusted Cowork folders list should not offer it either, or

1. It is safe, in which case the mid-task guard should exclude only the AppData\Roaming\Claude subtree and allow the rest of the home directory, matching what the picker already permits.

Whichever is chosen, the mid-session grant path and the task-start grant path should apply the same rule to the same path.

Error Messages/Logs

Guard response to `request_cowork_directory` with path `C:\Users\<user>`:


That directory is Cowork's internal session storage. Tool-result files are already
readable via the existing rules — read them directly. Other files there (transcripts,
session state) are intentionally not accessible. Request a project folder on the
user's machine instead.


Related read refusal for any path under the home directory when no folder is mounted:


`C:\Users\<user>` is outside this session's connected folders, so Glob can't reach it.

Steps to Reproduce

1. On Windows, open Claude Desktop and start a Cowork task without selecting a working folder.
2. Confirm in Settings > Cowork that C:\Users\<user> is present in the Trusted Cowork folders list.
3. Confirm that the task-start folder picker offers C:\Users\<user> as a selectable option.
4. In the running session, ask Claude to read any file under your home directory, for example C:\Users\<user>\Documents.
5. Claude issues a request_cowork_directory call for C:\Users\<user>.
6. The call is refused by the guard with the "internal session storage" message. No permission dialog is presented to the user, so there is no way to approve it.

Observed on Windows with Claude Desktop in Cowork mode. Requesting a narrower path that does not contain AppData\Roaming\Claude is not refused by the guard, which confirms the refusal is containment-based and that the whole home directory is being caught by it.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Desktop app, Cowork mode (not the Claude Code CLI). Version to be filled in by reporter.

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Context: this was hit during a normal working session. The user manages 30-plus client folders across %USERPROFILE%\My Drive\... and %USERPROFILE%\OneDrive\..., with instructions that reference absolute paths. Claude had every path in context and could open none of them, and the one grant that would have covered all of them was the one the guard refuses.

Possibly related, reported separately if it turns out to be distinct: on the same machine, one specific folder (%USERPROFILE%\My Drive (<account>)\Freelance) cannot be attached at all. Browsing to it via "Add a folder" in the task-start picker appears to select it but does not add it, with no error shown. A mid-session request_cowork_directory for that same path returns "User rejected" on repeated attempts. Its sibling folder under the identical Google Drive for Desktop root attaches normally and is offered by the picker. It is unconfirmed whether a permission dialog is presented to the user in that case.

Also observed in the same session, and consistent with #30457 and #39422: connectors shown as connected in the Connectors panel (GitHub Integration) expose no tools to the running Cowork session.