[BUG] Cowork: update retroactively invalidated custom Cowork files root; "Change location" then copied 12.87GB incl. credentials and git repo to world-readable /Library/Application Support/Claude
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, macOS (Apple Silicon), consumer account (Max plan), Cowork local sessions. Custom coworkUserFilesPath in use since 2026-06.
Summary of four related issues:
- RETROACTIVE CONFIG INVALIDATION WITH MISLEADING ERROR
Since June 2026, coworkUserFilesPath was set to my workspace folder (~/Workbot), which I also connected to sessions — valid and working for six weeks. After a recent update, connecting that folder fails with "This folder contains Claude's app data and can't be shared with this session." The folder contains no app data; the actual rule appears to be "connected folder must not equal the Cowork files root."
The error message misdescribes the condition, which cost hours of misdirected troubleshooting. Request: detect this legacy configuration on update and guide migration, and reword the error.
- UNSAFE COPY BEHAVIOR IN "CHANGE LOCATION FOR COWORK FILES"
While troubleshooting, I changed the Cowork files setting in the app as directed by Claude's AI support agent, to /Library/Application Support/Claude (a mistaken selection — note this system path is easily confused with ~/Library/Application Support/Claude). The app copied my entire 12.87GB workspace there, including a .git directory with a live remote and a Credentials folder, to a world-readable system-level location. The confirmation dialog does not warn about the size, contents, sensitivity, or destination visibility, and does not prevent selecting a system directory (or the app's own data directory) as the target. Request: block system paths and the app data directory as targets, show what will be copied, and warn on sensitive contents.
- SUPPORT AI CONFABULATED DIAGNOSIS
Anthropic's support AI twice insisted the cause was a "Claude-3p" directory nested in my workspace — conflating consumer Claude Desktop with the enterprise "Claude Desktop on 3P" deployment mode, which does not apply to my setup. This compounded the time lost.
- PER-FOLDER INSTRUCTIONS NOT DISCOVERABLE
Docs describe folder instructions for local folders on desktop, but no UI for them is findable in the folder picker, folder chip, hover, or right-click on the current macOS build. Either surface the feature or correct the docs. (Workaround used: Global instructions.)
Impact: ~4 hours lost; temporary exposure of credentials at a world-readable path; risk of divergent git pushes from the duplicate clone (avoided).
Resolution used, for reference: edited coworkUserFilesPath directly in claude_desktop_config.json to a fresh dedicated folder, verified the stray copy byte-for-byte, deleted it, and restored CLAUDE.md loading via Global instructions.
What Should Happen?
- Retroactive config invalidation: An app update that makes an existing configuration illegal should detect the legacy setup on first launch and present a guided migration ("Your Cowork files location is also a session folder — choose a new location for Cowork files"), rather than silently breaking a six-week-old working setup. The error message should describe the actual rule violated ("This folder is set as your Cowork files location and can't also be connected to a session") instead of the inaccurate "contains Claude's app data."
- Change location flow: The app should refuse system-level paths (/Library/...) and its own data directory as Cowork files targets. Before copying, the dialog should state the size and top-level contents of what will be copied and warn if the destination is more permissive than the source. Ideally offer "move" vs "copy," and never leave a duplicate of user data at a world-readable path without explicit acknowledgment.
- Support AI: When uncertain, the support agent should say so or escalate to a human, not assert a nonexistent directory ("Claude-3p") as a confident diagnosis for a consumer installation.
- Folder instructions: The per-folder instructions feature described in the docs should be reachable from the folder picker/chip UI, or the docs should be corrected to describe what actually exists.
Error Messages/Logs
"This folder contains Claude's app data and can't be shared with this session. Try a more specific folder instead."
(shown when connecting ~/Workbot, which was also the coworkUserFilesPath — the folder contains no app data)
"Change location for Cowork files? Copy files to ~/Workbot and restart the app. Your existing files will remain in /Library/Application Support/Claude."
(dialog offering to copy the app-data-mingled directory back into the workspace — no size/contents warning in either direction)
Steps to Reproduce
Setup: Claude Desktop on macOS with coworkUserFilesPath explicitly set to
a user workspace folder (e.g. /Users/<user>/Workbot) in
claude_desktop_config.json — a configuration that worked from June 2026
until a recent update.
Issue 1 (retroactive invalidation, misleading error):
- With coworkUserFilesPath set to /Users/<user>/Workbot, update to the
current app version.
- Start a Cowork session and connect /Users/<user>/Workbot.
- Observe error: "This folder contains Claude's app data and can't be
shared with this session" — although the folder contains no app data.
Actual rule appears to be: connected folder must not equal the Cowork
files root.
Issue 2 (unsafe copy):
- Open Settings > Cowork > Cowork files > Change.
- Select /Library/Application Support/Claude (system-level path; the
picker does not block it, and it is easily confused with
~/Library/Application Support/Claude).
- Confirm the single dialog.
- Observe: the app copies the entire Cowork files root (in my case
12.87GB including a .git directory with live remote and a Credentials
folder) to the world-readable system path, with no warning about size,
contents, or destination permissions.
- Attempt to change the location back to the workspace folder: the
dialog now offers to copy everything (including any app data at the
current location) into the workspace, which would then trigger Issue 1
permanently.
Issue 4 (folder instructions not discoverable):
- Connect a local folder to a Cowork session on macOS.
- Inspect the folder picker entry, folder chip, hover states, and
right-click menus.
- No per-folder instructions option exists anywhere, although the docs
describe folder instructions for local folders on desktop.
Claude Model
Sonnet (default)
Is this a regression?
Yes, this worked in a previous version
Last Working Version
Unknown — configuration worked from ~2026-06-08 until 2026-07-16; broke after an auto-update in that window.
Claude Code Version
Claude 1.22209.0 (77c938) 2026-07-16T05:39:45.000Z (Claude Desktop; this is a Desktop/Cowork bug, not CLI.)
Platform
Other
Operating System
macOS
Terminal/Shell
Other
Additional Information
Platform and Terminal/Shell are both "Other" because this is a Claude Desktop / Cowork GUI bug on a Max subscription — no API, no CLI, no terminal involved in the bug itself.
Timeline: configuration (coworkUserFilesPath = workspace folder) was set up ~2026-06-08 following common community guidance and worked daily until 2026-07-16, when it broke after an app auto-update. This suggests other users who customized the Cowork files location to their workspace folder will hit the same wall on update.
Screenshots attached:
- The "Change location for Cowork files?" dialog offering to copy
/Library/Application Support/Claude into the workspace folder — note
no contents/size warning in either direction.
- (Optional) The folder permission prompt post-fix, for contrast.
Anthropic's AI support agent was consulted during the incident and twice asserted a nonexistent "~/Library/Application Support/Claude-3p/" directory as the diagnosis — apparently conflating consumer Claude Desktop with the enterprise "Claude Desktop on 3P" deployment mode.
Transcript excerpt available on request.
Happy to provide sanitized config excerpts or answer follow-ups. I have not included my claude_desktop_config.json since the relevant key is fully described above.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗