[BUG] Cowork: reserved folder names permanently block connecting a working folder — renaming can't fix it because the app recreates them

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?

Summary
Cowork refuses to connect any folder containing subfolders named Skills, Scheduled or Artifacts, reporting "This folder contains Claude's app data and can't be shared with this session." Those names are not app data — the desktop app's real data lives in ~/Library/Application Support/Claude. They are ordinary user folders that happen to share reserved names.

The block cannot be worked around, because Cowork recreates those folders inside the working directory after they are renamed away. The user is left with a folder that can never be connected and no action they can take to change that.
Environment
macOS, arm64
Claude desktop app 1.37937.1 (Electron 42.10.0, Node 24.18.1)
Cowork cloud session with device folder bridge
Observed 26 August 2026
Affected folder: ~/Claude New, used as a Cowork working directory for several months without issue
What happens
~/Claude New contains user-created subfolders: Artifacts, Cowork, HTML Outputs, Projects, Scheduled, Skills.

Connecting ~/Claude New fails with the "contains Claude's app data" toast.
The session is nonetheless told at startup that the folder is connected, while get_device_info reports it is not — so the session and the app disagree about what is connected.
device_request_folder_access on the root returns "A requested folder can't be granted to this session."
Paths below the root return names-only skeletons, confirming the folder exists and is readable at directory level. The root itself returns the same error text as a non-existent path.
Why it can't be worked around
Following the toast's own advice ("try a more specific folder"), the user renamed the three colliding folders:

Artifacts → Artifact Files
Scheduled → Scheduled Tasks
Skills → Skill Files

The renames succeeded on disk. The root was still blocked. Within the same session, Skills re-created itself inside ~/Claude New.

So the app creates folders by reserved names in the user's working directory, then refuses to connect any directory containing folders by those names. No arrangement of the user's files escapes this, because the app restores the trigger.
These are not app data
The desktop app's actual data directory is ~/Library/Application Support/Claude. It contains blob_storage, Cache, claude-code, claude-code-sessions, claude-code-vm, Code Cache, Crashpad, File System, IndexedDB, Local Storage, local-agent-mode-sessions, Partitions, pending-uploads, sentry, Session Storage, vm_bundles, WebStorage, plus config.json and claude_desktop_config.json.

There is no Skills, Scheduled or Artifacts folder anywhere in it. The folders being rejected in ~/Claude New hold the user's own material: .skill archives, a skills index document, SKILL.md files and a Python script supporting scheduled tasks.

What Should Happen?

Expected behaviour
Connecting a user folder should succeed regardless of what its subfolders are called. If Cowork needs private storage, it belongs in ~/Library/Application Support/Claude alongside everything else, not in the user's working directory — and certainly not as a condition that makes that directory unconnectable.

Error Messages/Logs

"This folder contains Claude's app data and can't be shared with this session. Try a more specific folder instead."

Steps to Reproduce

Steps to reproduce
Create a folder, e.g. ~/Test Workspace.
Create subfolders Skills, Scheduled and Artifacts inside it, with files in them.
Attempt to connect ~/Test Workspace to a Cowork session → refused as containing Claude's app data.
Rename all three subfolders to non-reserved names.
Attempt to connect again → still refused; observe reserved-named folders reappearing in the directory.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

1.37937.1,

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Impact
A working folder built up over months became permanently unconnectable after an app update, with no user-side remedy.
The error message misattributes the cause to the user's folder, sending them to reorganise files that were never the problem.
Renaming to escape the block silently breaks hardcoded paths in skills and scheduled-task scripts. In this case two absolute paths in a scheduled task's SKILL.md broke and had to be repaired by hand.
The documented workaround (connect child folders individually) requires connecting five or six folders in place of one, and Scheduled still could not be granted programmatically at all.
Suggested fixes, in order of preference
Stop creating reserved-name folders inside user working directories; keep Cowork's storage in the app support directory.
If they must live there, identify them by a marker file or stored path rather than by name, so user folders that share a name are unaffected.
At minimum, don't block the parent — exclude the reserved subfolders from the mount instead of rejecting the whole directory.
Fix the error message to name the specific offending subfolder, so the cause is diagnosable.
Related
#71307 — reserved Scheduled path overlap blocks mounting a parent folder; reported as a regression.
#86647 — session reports zero connected folders while the project UI shows one as connected. The session/app disagreement in step 2 above looks like the same fault.

Two further issues observed alongside this, possibly related, reported separately if useful: a connected folder that consistently fails to mount into the session shell while remaining reachable through the staging tools, and a project-bound folder that offers no way to disconnect it (no remove control, unlike ordinary connected folders).