[FEATURE]

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

I'm a researcher whose entire working life lives in Dropbox on a secondary drive (E:). This is a 25+ year workflow—my project files, data, and documents all live there, not in C:\Users\<username>\Documents.
Cowork looked like exactly what I needed: an agentic tool that organizes threads into projects while having filesystem access to my actual working files. But the home-directory restriction means Cowork can't see any of my content.
I'm aware of the symlink/junction workaround attempts described in #24964 and #29583—they don't work because fs.realpath() resolves back to the real path and rejects it.
My current fallback is Claude Code in WSL, which has no folder restrictions and works beautifully with /mnt/e/Dropbox/.... But Claude Code lacks the project organization layer that Cowork provides—there's no way to group related sessions, maintain project-level context across threads, or come back to a structured workspace. So I'm stuck choosing between filesystem access (Claude Code) and project organization (Cowork), when the whole point of Cowork was to offer both.
This isn't an edge case. Many Windows power users keep working files on secondary drives or in cloud-synced folders outside the home directory. Dropbox, OneDrive, and Google Drive all allow users to choose non-default locations. The restriction as implemented assumes a workflow that doesn't reflect how a lot of people actually organize their machines.
I'd strongly encourage the team to relax this to any folder the user has OS-level permissions to access, or at minimum, accept symlinks/junctions without resolving them.

Proposed Solution

Proposed solution:
A tiered approach, in order of preference:

1. Remove the home-directory restriction entirely. Let the user select any folder they have OS-level read/write permissions on. The OS already enforces access control—there's no need for Cowork to second-guess it. The folder picker dialog itself is an explicit grant of consent, just like any other application that asks "choose a folder."
2. If a blanket allowlist feels too permissive, let users register trusted paths in Cowork's settings. Something like an "Additional folders" list where I can add E:\Dropbox once, and Cowork treats it as a valid root going forward. This preserves the intentionality of the current design without assuming everyone's files live under C:\Users.

Any one of these would unblock the many users whose workflows depend on secondary drives or non-default cloud sync locations.

Alternative Solutions

_No response_

Priority

Critical - Blocking my work

Feature Category

CLI commands and flags

Use Case Example

_No response_

Additional Context

_No response_