[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

Status Open
Maintainer reply None cached
Activity 1 comment · opened Jul 17, 2026

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:

  1. 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.

  1. 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.

  1. 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.

  1. 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?

  1. 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."
  1. 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.
  1. 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.
  1. 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):

  1. With coworkUserFilesPath set to /Users/<user>/Workbot, update to the

current app version.

  1. Start a Cowork session and connect /Users/<user>/Workbot.
  2. 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):

  1. Open Settings > Cowork > Cowork files > Change.
  2. Select /Library/Application Support/Claude (system-level path; the

picker does not block it, and it is easily confused with
~/Library/Application Support/Claude).

  1. Confirm the single dialog.
  2. 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.

  1. 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):

  1. Connect a local folder to a Cowork session on macOS.
  2. Inspect the folder picker entry, folder chip, hover states, and

right-click menus.

  1. 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:

  1. 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.

  1. (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.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗