[BUG] Cowork: cannot remove a project's original folder from project context (no remove control)
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?
A Cowork project's founding folder cannot be removed from the project's contents/context in the Claude desktop app. Folders added to the project later show a remove control; the folder the project was originally created around shows none at all — no hover X, and nothing in any menu.
Steps to reproduce:
- Create a Cowork project bound to local folder A (e.g.
~/Documents/Cowork/Voice-Task) - Rename/move folder A on disk (e.g. to
~/Documents/Cowork/SayWork) - Add folder B (the renamed folder) to the project's context
- Try to remove folder A from the project page's contents section
Actual behavior:
- Folder A has no remove control anywhere in the UI (folder B, added later, has one and removes fine)
- Persists after a full app restart (Cmd-Q)
- Persists after recreating folder A on disk so the path resolves again
- Every new session in the project still auto-connects the stale folder A
- Side effect: if the stale folder is deleted on disk, the desktop file bridge silently recreates it the moment a session writes anything to its mount — so the stale reference "resurrects" deleted folders
Possibly related: #21274 (Cowork folder stuck, cannot change), #56688 (primary working directory locked to a different folder).
What Should Happen?
Any connected folder should be removable from a project's context — including the folder the project was originally created with — or at minimum there should be a way to re-point the project's primary folder after a rename on disk.
Environment: Claude desktop app 1.20186.1, macOS (arm64), Electron 42.5.1.
Error Messages/Logs
Steps to Reproduce
- In the Claude desktop app, create a Cowork project bound to a local folder A (e.g.
~/Documents/Cowork/Voice-Task) - Later, rename/move folder A on disk (e.g. to
~/Documents/Cowork/SayWork) - Add folder B (the renamed folder) to the project's context from the project page
- Attempt to remove folder A from the project page's contents/context section
- Observe: folder B shows a remove control and removes fine; folder A has no remove control at all (hover, right-click, and menus all show nothing)
- Fully quit and reopen the app — unchanged. Recreate folder A on disk so the path resolves — unchanged.
Claude Model
None
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
Claude desktop app 1.20186.1 (Cowork), Electron 42.5.1
Platform
Other
Operating System
macOS
Terminal/Shell
Other
Additional Information
This is the Claude desktop app (Cowork), not the CLI — filing here since Cowork desktop bugs (e.g. #21274) are tracked in this repo. The stale founding folder is auto-connected to every new session in the project, and because the remote session's file bridge recreates the folder on write, deleting it from disk doesn't stick. Happy to provide logs or a screen recording if useful.
3 Comments
Additional data point — Windows 11, Claude Desktop 1.24012.9 (03c61d). Still reproduces on a much newer build than the 1.20186.1 reported here. I can also narrow the trigger of the "resurrection" side effect.
Controlled repro isolating the cause: I created a test project with a base folder chosen in the "Create a project" dialog, then added three more folders via "+" next to Context. All four exist on disk and are valid. The three added folders each show an "x" on hover and detach fine; the base folder has no remove control at all. This rules out a stale/unresolvable path and a permissions issue — every folder exists, and three of them are removable in the same panel. The missing control tracks the entry's role, not its state on disk.
Separately, in a long-running project of mine the base folder no longer exists on disk (the directory was moved months ago), so that entry is permanently stale and unremovable.
On the resurrection side effect, on Windows:
So on Windows the impact is cosmetic (deletion doesn't stick) rather than data-scattering, but the stale entry remains permanently unremovable.
Note on scope: this is Claude Desktop (Cowork), not the Claude Code CLI.
Hi, I just wanted to corroborate this. The original context folder in a Claude project cannot be erased, so it looks it up everytime the project starts, even if the folder no longer exists. The new context folder has an "X" that allows it to be deleted from the project, but the original context folder cannot be removed.
macOS data point that differs from @LukMC76's Windows timing, plus a storage finding and a question about a backend remedy.
Case. Project created via "Start from scratch", which per the docs creates the project with a new folder. That founding folder landed inside a cloud-synced shared document library with an enforced folder taxonomy, so here the stale entry is a compliance problem, not a cosmetic one — an unexpected top-level folder in that tree is an audit finding. The folder is empty and always has been; all real work happens in the three other folders attached to the project.
Resurrection is immediate on macOS, not deferred. @LukMC76 reports that on Windows the folder only reappears once the session creates a file and runs a local command. On macOS (desktop 1.46388.3, Electron 42.10.0) it came back inside the same shell command that moved it:
mvof the folder to another directory: succeededmvsucceeding rules out filesystem permissions. Matches Windows in one respect: the recreated directory is empty — mount point only, no content.There is no editable config to work around it. On macOS:
config.json— 0 hits for any attached folder pathbridge-state.json— 0 hitsclaude_desktop_config.json, which is MCP server configuration, not the project's folder listThe folder list therefore appears to live in a binary store (LevelDB/IndexedDB, or inside the VM image) — no supported file to hand-edit, which closes off the workaround people would otherwise reach for.
Why archive-and-recreate is not an acceptable workaround. Per the docs, archiving a project deletes its metadata including memory. For a project with a large accumulated memory store that is destructive, and #76694 reports post-merge projects lost "Choose a folder" entirely — so a rebuilt project risks losing its memory and being unable to re-attach the original folders.
Question: is there a support-side or backend way to remove a founding folder from an existing project's folder list, without archiving the project or losing its memory store? A one-off edit would fully resolve this here; the UI control does not need to ship first.