[BUG] Revoking local folder access does not terminate an already-active session mount

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?

Environment: Claude Desktop for macOS, Cowork session, 24 August 2026

Summary

Once a folder has been connected to a running Cowork session, revoking access — through the app's settings and through macOS System Settings → Privacy & Security → Files and Folders — has no effect on that session. Claude retains full read and write access to the folder until the conversation itself is abandoned.

Actual: Claude continues to list all 108 items in the folder. I also confirmed the access is live rather than cached — Claude successfully wrote a new file into the folder after both revocations. The access persisted across roughly 40 minutes and multiple revocation attempts.

What Should Happen?

Claude reports it no longer has access.

Error Messages/Logs

None. The failure is silent — no error was produced at any point. I do not have logs to attach.

Steps to Reproduce

1. Start a Cowork session and connect a local folder (in my case the iCloud Drive root) via the native folder picker.
2. Remove the folder from the app's connected-folders list.
3. Additionally uncheck Claude in System Settings → Privacy & Security → Files and Folders.
4. Ask Claude to list the folder.

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

N/A

Claude Code Version

N/A — this is a Claude Desktop / Cowork issue, not Claude Code CLI. Claude Desktop for macOS, version not recorded.

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Non-interactive/CI environment

Additional Information

Why this matters

The folder I connected was the iCloud Drive root, which holds my driver's licence, bank receipts, rental contracts and a health declaration. When I realised the scope was wrong, I tried to withdraw access and could not. Revocation controls that do not take effect are worse than no controls, because the user believes the exposure has ended when it has not.

Two contributing problems:

1. No discoverable way to revoke. I could not locate the control in the app; support documentation does not describe the steps. Claude could not find it either.
2. No way to ask the agent to disconnect. There is a tool to request folder access but no counterpart to release it, so "disconnect from my folder" is not an executable instruction.

Suggestions

• Tear down active session mounts immediately when access is revoked, rather than only applying the change to new sessions.
• Surface a clear, documented control for viewing and removing connected folders.
• Consider giving the agent a release-access capability, so a user's request to disconnect can actually be carried out.
• Warn at connection time when the selected folder is a broad root directory such as the iCloud Drive or home folder.

Related: #27162 (same failure in a new session after force quit), #40043 (no UI control to remove a connected folder).

I am reporting this after the fact and have no logs or reproduction to attach.