Skip to main content
Like standard Cowork, Cowork on third-party (3P) works directly with files on the user’s computer. Users attach one or more workspace folders to a session; the agent can then read, create, and modify files anywhere inside those folders, and run code against them inside the sandbox VM. In Cowork on 3P, administrators can constrain which folders users are allowed to attach.

​
Workspace folder allowlist

The allowedWorkspaceFolders configuration key restricts which paths users may attach as workspace folders.
ValueBehavior
UnsetUnrestricted. Users can attach any folder they have OS-level access to, matching standard Cowork.
["~/Documents/Claude", "/Volumes/Shared/Projects"]Users may attach only folders inside one of the listed roots.
[]No folders may be attached. The agent can still create files in its own sandbox scratch space, but cannot read or write the user’s filesystem.
A leading ~ expands to the user’s home directory, so a single profile can express per-user roots like ~/Documents/Claude across the fleet. The check is enforced against the resolved path, so symlinks and .. traversal can’t be used to escape an allowed root. On Windows, network locations — both mapped network drives and UNC paths — aren’t currently supported as workspace folders.
The allowlist controls what users can attach. Within an attached folder, the agent has full read/write access to every file the user’s OS account can reach. To isolate sensitive data, keep it outside the allowed roots.