Allow removal of local folders from a Cowork project's context
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
When a local folder is added to a Cowork project's context, there is no way to remove it from within the UI. If the folder was added by mistake, is no longer relevant to the project, or contains files that should no longer be in scope, there's nothing you can do. You can't delete the project entirely and start again either.
This is a basic project management function that would make Cowork projects more useful for ongoing or evolving work.
It is also relevant to reducing data exposure and privacy risks.
Proposed Solution
Expected behaviour: a remove or unlink option should appear alongside the folder listing in the project context panel, allowing users to detach a folder without affecting the folder itself or the rest of the project.
Alternative Solutions
Allow users to delete projects in Cowork.
Priority
High - Significant impact on productivity
Feature Category
CLI commands and flags
Use Case Example
_No response_
Additional Context
_No response_
28 Comments
I totally agree. It's a basic security feature too. Files no longer relevant or off limits by claude should be excluded at any point. the user should be in control what claude can access at any time without starting from scratch and losing important memories and scheduled tasks etc.
Agreed +1
Workaround: edit file "spaces.json" buried in a couple of UUID folders under '/Users/$user/Library/Application Support/Claude/local-agent-mode-sessions'. Here you'll find the "folders" array per project. Delete any folders Claude should no longer have access to and save the file. Beware of syntax. Relaunch Claude. It did the trick for me.
To quickly discover where the spaces.json file lives, preview any memory file in your project in claude, click the "show in finder" icon in the top right corner and move ± 2 levels up from there.
THANK YOU FOR YOUR ATTENTION TO THIS IMPORTANT MATTER (no really thank you)
This kind of complete mess must be made by AI coder.
THIS WORKED. But Anthropic team, there needs to be a way to clear the initial project folder or select an alternate.
<img width="1509" height="1125" alt="Image" src="https://github.com/user-attachments/assets/1e41949c-9d73-4609-ac77-6ec9a43e9123" />
<img width="1369" height="955" alt="Image" src="https://github.com/user-attachments/assets/109c0cdb-8a99-4303-a2e4-9337ba2caff9" />
18/05/2026 — still no basic “delete folder” feature.
It’s hard to understand how a company capable of building frontier AI models can leave such a trivial UX limitation unresolved for this long.
This isn’t a complex systems problem, it’s a basic file management action. At this point it feels more neglected than difficult.
Agree
+1
Agree. I ran into this today on the Cowork desktop app. I created a new project and designated a parent folder as context. Because I didn't say "existing project', Cowork mounted both a parent folder and a new nested subfolder of the same path to a project's context. I can't delete Cowork's new folder.
The only workarounds I was given were (1) start a brand new Cowork project and re-add just the folder I want, or (2) wipe the entire LevelDB store, which clears all app state and forces re-auth. Both are disproportionate to the ask, which is just "let me unlink one folder from this project."
Agreed. Just started my first cowork project and now I have this phantom folder I can't get rid of from my context section. This should be a relatively simple fix for anthropic so hopefully someone will get to this and resolve it.
It's still unresolved
<img width="692" height="191" alt="Image" src="https://github.com/user-attachments/assets/0a39243b-630f-47ef-8932-c417828c64ed" />
제목: Cowork 프로젝트 컨텍스트에서 폴더를 제거할 수 없음 (재시작·폴더 삭제 후에도 잔존)
환경: Cowork v1.10628.0, macOS
문제: 프로젝트 컨텍스트("컴퓨터에서")에 추가된 빈 폴더를 제거할 UI가 없음. 컨텍스트 항목에 hover해도 ✕/⋯ 미표시, ⋮ 메뉴·세부사항 수정 모두 폴더 관리 기능 없음. 실제 폴더를 Finder에서 삭제하고 앱을 재시작해도 해당 참조가 목록에 그대로 남음.
기대 동작: 컨텍스트 패널의 각 폴더 옆에 제거/연결 해제 옵션 제공, 그리고 삭제된 폴더의 잔존 참조 자동 정리.
재현: 폴더 연결 → Finder에서 폴더 삭제 → 앱 재시작 → 참조 잔존 확인.
having the same issue
Thank you so much! For me it worked... But I'm really surprised that it's not straightforward...
On my Windows laptop, the folder is something like:
"C:\Users\$user$\AppData\Roaming\Claude\local-agent-mode-sessions\" Then I had to search the file "spaces.json" as it was located in a subfolder1\subfolder2.
No wonder Nate B Jones is having a Codex moment. This is really bad Anthropic.
Workaround: remove / repoint local folders in a Cowork project (macOS)
Until there's a UI option, you can fix the folder list directly. Claude Cowork stores each project's attached folders in
spaces.json, under:The script below edits that file safely — dry-run preview, confirmation, timestamped backup, JSON re-validation with automatic rollback. It never touches your actual folders, only the references.
Usage
~/Downloads/fix_cowork_folders.py).spaces.json.Notes
pgrep). Requires Python 3 (preinstalled on recent macOS / Xcode CLT).spaces.json.bak-<timestamp>. Delete them once you've confirmed things work.<details>
<summary><b>fix_cowork_folders.py</b> (click to expand)</summary>
</details>
+1 on the original ask (unlink option in the project context panel), and on the alternative solution already proposed here (allow deleting Cowork projects), either would let users recover from this without guesswork.
Environment: Windows 11 Pro, Claude Desktop v1.21459.0 (f7518f), Cowork
Ran into this today, plus a more serious related failure. (Windows 11 Pro)
I hit the exact problem described here (no way to unlink a folder from a Cowork project's context), and also confirmed there's no way to delete a Cowork project at all, only Archive, which just hides it from the UI without removing the folder reference or any underlying local data.
More concerning: this isn't just an inconvenience, it caused a full service outage.
As a workaround, I renamed the local folder linked to a project, expecting the project to just show that folder as missing. Instead, the entire Cowork VM service failed to start, "Failed to start Claude's workspace / VM service not running", even when trying to create a brand-new, unrelated project afterward. Archiving the affected project didn't resolve it either. A full computer restart was required to recover.
So the combination of these gaps means a routine action (renaming/moving a folder, something a user could easily do by accident, e.g. via normal file organization) can take down Cowork entirely, with no in-app way to unlink, delete, or otherwise recover the broken project reference short of a system reboot.
+1, with a concrete case showing why this gap is worse than an inconvenience.
I run a curated standards library for my business through Cowork projects. As part of a restructure I renamed a folder, and the old empty folder needed deleting. Simple enough, except the old folder was one of the project's connected folders, and that turned a ten second tidy-up into a dead end:
Consider what this means in practice. Connecting a folder is a one-way, permanent grant for the life of the project. If a folder is connected by accident, or later turns out to contain sensitive material, there is no way to withdraw access short of abandoning the project and its history. A permission you can grant but never revoke would not pass review in any other product; it should not exist here. The same assistant inside the session can correctly tell me the folder should go, and then has to watch the app resurrect it every time.
The fix requested in this issue (a remove or unlink option next to each connected folder) would have made my case a non-event. I would ask that it be treated as a data-access control gap, not a convenience enhancement, and prioritised accordingly.
At this point just ditch cowork completely and work from Claude code exclusively. It’s the same engine underneath the hood and you get far better control over everything. You can use git version control natively , see context window, switch model and effort in the same session, terminal access and therefore computer control is built in, setup remote control. Memory can be done in md files that are portable across AI vendors so you’re not locked in to Anthropic…Best part of course is that one can easily switch folders if things change. the code tab is not merely for programmers!
Shocked that this is still an issue that has not been resolved. Especially if Anthropic is trying to attract new users, this is the kind of gap that would be a huge turnoff to someone trying to learn how to manage context.
I too am very disappointed in this. I just purchased a Mac M5 specifically for AI coding and finding more limitations here than from the Windows OS. Anthropotic, please fix this!!!! Looks like I will be configuring for Claude Code moving forward.
came here to say this is crazy it's still a problem
Came here to agree with @ghost-ng
Full Disclosure: I'm not a developer. I hit this on one of my own projects where context was becoming stale and bloated with duplicates, needed it fixed, and built a small app with a lot of AI help to fully manage said context (local and cloud). So it's vibecoded, and so is the technical aspect of this comment. Worth knowing before you point it at files you care about.
One thing Claude ran into that I haven't seen mentioned in this thread, useful even if you ignore my tool:
spaces.jsonisn't the only file. Next to it isremote-session-spaces.json, holding per-session folder grants ({ sessionId, spaceId, folders: [...] }). When a session starts, the folders stored there get unioned with the ones the session brings — so a path you deleted fromspaces.jsoncan come back from a stale grant. If you removed a folder, relaunched, and later saw it return, that's probably why. The complete manual fix is to remove the path from both files, with Claude fully quit first.If you'd rather not hand-edit JSON, mine is MIT and macOS-only: https://github.com/earsenio/cpcm
It refuses to run while Claude is open, backs up before writing, re-validates and rolls back if anything looks wrong, and
--dry-runshows the diff without changing anything. Build from source — given the above, you should be able to read what you're running.Thanks to @shifthappens and @Petijaune, whose workarounds got me unstuck in the first place. My app does have an unlink button — but it's still a workaround, not a fix: macOS only, unofficial, you have to quit Claude first, and it'll break whenever the file format changes. A real one inside Cowork is the answer, so please keep this issue open.
Definitivamente es algo que tienen que mejorar. Además de el reto de hacer aún más intuitiva toda la herramienta.
If we can add something to a project context it seems super basic that we can remove it too...mistakes were made.
Bugs are expected, but it is criminal that there are bugs and feature requests that have been around for many months, considering that Anthropic is nearly a TRILLION dollar company.
Hitting a variant of this: my connected folder now shows as 'empty' but the underlying local path doesn't exist on disk anymore (confirmed via ls). The stale reference just sits there in the Context panel with no way to unlink it.