[BUG] Cowork: trusted-folder validation rejects Shared Drive root AND first-level folders after app update; depth-2 folders pass

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?

After a Claude desktop auto-update (on or around 2026-07-09), Cowork's trusted-folder validation began rejecting Google Shared Drive roots AND their first-level folders. Folders at depth 2 or deeper pass validation and work normally.

Impact/behavior details:

• Selecting the Shared Drive root: "This folder can't be added" dialog (root/protected/invalid message). The per-session authorization prompt never appears - rejection is pre-authorization.
• Selecting a FIRST-LEVEL folder inside the Shared Drive: "1 folder was skipped because it overlaps a protected location or is the home/root directory."
• Selecting a SECOND-LEVEL folder: passes validation, authorization prompt appears, folder connects and works fully (read/write/bash).
• Existing folder grants appear grandfathered across the update: two teammates with pre-existing connections (and/or older builds) kept working for 2+ days, which disguised the regression as machine-specific and cost us many hours. Removing trusted folders during troubleshooting forfeits the grandfathered access permanently.
• Same first-level paths connected successfully the morning of 2026-07-09, before the app updated mid-day.

Our 3-person team shares a Google Shared Drive as the common Cowork workspace. Workaround that restored service: restructure the drive so the workspace folder sits at depth 2 (Shared drive/Team/WORKSPACE) and connect that.

What Should Happen?

First-level folders inside a Google Shared Drive are ordinary user-content folders and should pass trusted-folder validation (or, if the depth restriction is intentional, the error should say so explicitly - "connect a more deeply nested folder" - instead of the generic root/protected message).

Also expected: validation behavior consistent between Settings -> trusted folders and the in-session Add folder flow, and some warning before an update strands users whose existing workspace sits at a now-invalid depth.

Error Messages/Logs

Drive root selection:
"This folder can't be added
Home, root, protected locations, and invalid paths can't be trusted folders. Choose a more specific folder."

First-level folder selection:
"1 folder was skipped because it overlaps a protected location or is the home/root directory."

Steps to Reproduce

1. macOS (Apple Silicon), Google Drive for desktop signed in, member of a Google Shared Drive (streaming/File Provider mount under ~/Library/CloudStorage - note Shared Drives cannot be mirrored elsewhere, per Google).
2. Claude desktop app, current build as of 2026-07-09/10, Cowork -> Add folder.
3. Select the Shared Drive root (~/Library/CloudStorage/GoogleDrive-<email>/Shared drives/<DriveName>) -> rejected with "This folder can't be added".
4. Select any first-level folder inside the drive -> "1 folder was skipped because it overlaps a protected location or is the home/root directory."
5. Select any second-level folder -> passes; authorization prompt appears; connects and works.
6. Compare with a machine that connected the same first-level path before the update: it continues to work (grandfathered).

Claude Model

_No response_

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Build prior to the 2026-07-09 auto-update (same paths connected that morning)

Claude Code Version

1.19367.0 (and current build as of 2026-07-10); Electron 42.5.1; macOS arm64

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

• App version observed failing: 1.19367.0 and the build current as of 2026-07-10. First-level folders on the same machine connected fine the morning of 2026-07-09 before an auto-update.
• macOS Full Disk Access / Files & Folders permissions ruled out: enabling FDA for Claude and restarting changed nothing.
• Reproduced across two different Macs with two different Claude accounts.
• Google-side relocation is impossible: Shared Drives can only be streamed to ~/Library/CloudStorage (mirror mode is My Drive only), so affected teams cannot move the mount - only add nesting depth.
• Encountered while investigating workarounds: Cowork cloud sandboxes cannot be granted private GitHub repo access (git proxy "authorized repository set", no add_repo mechanism exposed in Cowork; the claude.ai/code GitHub App connection does not propagate) - related to #64130. This foreclosed a git-based workaround and is worth fixing independently.
• Suggested fixes: allow first-level Shared Drive folders; or make the depth rule explicit in the error text; and surface a migration warning for grandfathered connections that will fail on re-add.