[BUG] Cowork mounted a folder into a project session that was never attached to that project, read-write

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 Cowork session started from a project mounted a local directory read-write that had never been attached to that project. In the same session, a folder that had been attached to the project was absent. So the set of mounted folders is not the project's set of attached folders, and the two diverge in both directions at once.

The directory that appeared unexpectedly belongs to unrelated work and has no connection to the project the session was started from.

Where it might have come from — a lead, not a cause. The only place that directory was recorded anywhere on disk was the global trusted-folder list — preferences.localAgentModeTrustedFolders in claude_desktop_config.json. It was not among the project's folders, and it is not in preferences.remoteSessionFolderGrants either, which records per-session grants and lists no session holding it. So the mount has no visible source in either the per-project or the per-session record; the approved-paths list is the only place it appears at all.

I am deliberately not claiming that list causes the mount — see Steps to Reproduce for why the obvious test does not isolate it. But if session mounts can draw on it, then that list is a record of "the user approved this path at some point", not "this project may use this path" — and every path a user has ever approved becomes a candidate for being mounted read-write into any project's session — including sessions that browse the web or talk to third-party services. Anyone keeping separate projects for separate clients, or working under confidentiality obligations, would reasonably expect a project boundary to be a boundary.

Related: #75970 asks for a way to revoke folder access and is currently filed as an enhancement. This is the reason revocation matters — an entry that cannot be removed is an entry that can be mounted somewhere it was never granted. #76187 makes this harder to notice: with project attachments not persisting, a panel showing no folders (or the wrong ones) reads as that known bug rather than as a mount that should not be there.

What Should Happen?

A session's mounted folders should be exactly the folders attached to the project it was started from. A path in the trusted/approved list should mean "the user has consented to this path being mountable", never "mount it". If there is a supported way to scope an approved folder to a single project, it isn't discoverable.

Error Messages/Logs

No error. That is the problem — the extra folder mounts silently and reads as normal.

When *nothing* mounts, the failure does surface at the tool layer:


No folders are connected to this device for the current session. Call
device_request_folder_access with the folder you need (the user is asked to approve),
or ask the user to connect a folder; then retry.

Steps to Reproduce

1. Approve folder X for Cowork at some point (any project, or a mid-session grant).
2. Create or open a different project, and attach only folder Y to it.
3. Start a session from that project and list the connected folders.
4. Observed: X is mounted read-write although it was never attached to this project; Y may be

absent.

1. Remove X from the trusted-folder list, quit and reopen, start a session from the same project

again — X no longer appears in the mounts.

⚠️ Step 5 is not a clean control, and I would rather say so than overstate it. After that
prune the next session mounted nothing at all — including a folder that was still in the
trusted list and had mounted before. So the result is equally consistent with *"pruning removed
X" and with "by then nothing was mounting anyway"*, which is plausible given #76187. It does not
isolate the trusted list as the source.

Step 4 is not in doubt: a directory never attached to the project was mounted read-write into
that project's session, and the session itself reported it when asked what it could see.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Desktop 1.37937.0 (61bfd4)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Both folders are on a secondary drive (D:), cf. #26103 and #29583.

Two questions for maintainers:

1. Is the trusted-folder list intended to contribute to a session's mounts, or should mounts come

only from the project's own attachments?

1. Is there any supported way to scope an approved folder to a single project?