[BUG] Cowork: new projects lost "Choose a folder" — Context menu replaced with Chat-style upload-only knowledge menu after Chat/Cowork merge
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
Since the Chat/Cowork merge rollout (~July 8–9, 2026), newly created projects no longer offer the "Choose a folder" option in the Context panel. The Cowork-native context menu has been replaced wholesale with the Chat-style project knowledge menu, which only supports static context (file uploads, pasted text, GitHub/Drive/Notion imports). There is no way to link a local folder to a new project for dynamic, living-file context.
Projects created before the merge retain the old menu and their linked folders (grandfathered).
Steps to Reproduce
- Claude Desktop on macOS, post-merge build (merge rolled out ~July 8–9, 2026)
- Create a new project
- In the project view, click the + next to Context
- Observe the menu options
Actual Behavior
Context "+" menu on new projects shows only:
- Upload from device
- Add text content
- GitHub
- Drive
- Notion
This is the Chat project "knowledge" menu (static snapshot context). "Choose a folder" is absent entirely — this is not a folder-picker validation failure; the menu itself is different. Even the Context empty-state copy is Chat's ("Add PDFs, docs…").
Comparison (screenshots attached)
- Screenshot 1 — pre-merge project: Context "+" → Choose a folder / Drive / Add a link. Multiple locally linked folders visible and working in the Context list.
- Screenshot 2 — project created post-merge: Context "+" → Upload from device / Add text content / GitHub / Drive / Notion. No folder option.
Why This Matters
Linking a folder (dynamic context tied to living files, e.g. Obsidian vaults that sessions read and write) is categorically different from uploading files (static snapshot). Folder-linked projects are the core Cowork workflow; new projects currently cannot use it at all.
Environment
- OS: macOS (Apple Silicon MacBook Pro)
- App: Claude Desktop, post-merge build (auto-updated ~July 9, 2026)
- Regression: Yes — worked until the Chat/Cowork merge rollout; discovered July 10, 2026
Related Issues (same rollout window)
- #76604 — Cowork broken since Chat/Cowork merge: projects disappear within 24h
- #76254 — trusted-folder validation rejects previously-accepted folders since ~July 9 update; existing grants grandfathered
- #76344 — connected folders no longer writable-mounted since mandatory write-consent change (~July 8)
- #76573 — cannot remove a project's original folder from context
Notes
- Pre-merge projects keep the old Context menu and their folder links — consistent with grandfathered grants noted in #76254. (Users should be warned not to unlink folders from old projects, since re-adding appears impossible in new-style projects.)
- In-session "Add folder" (session-level device bridge) still functions, but is per-session and not persisted as project context — a partial workaround, not a substitute.
<img width="1306" height="735" alt="Image" src="https://github.com/user-attachments/assets/7f88c241-fdc5-47ac-8371-e30ec5d02a69" />
<img width="1306" height="735" alt="Image" src="https://github.com/user-attachments/assets/c79bfe70-8e5b-4950-b5f7-c4e170451083" />
What Should Happen?
The Context "+" menu on a newly created project should offer Choose a folder (link a local folder on this computer as live, dynamic project context), plus Drive and Add a link — exactly as pre-merge projects still show, and as documented in the support article "Organize your tasks with projects in Claude Cowork" ("Use an existing folder on your computer").
Error Messages/Logs
Steps to Reproduce
- Use Claude Desktop on macOS with a post-merge build (auto-updated during the Chat/Cowork merge rollout, ~July 8–9, 2026)
- Create a new project
- In the project view, click the + button next to Context
- Observe the menu: Upload from device / Add text content / GitHub / Drive / Notion — "Choose a folder" is absent
- For comparison, open any project created before the merge and click the same + next to Context: the menu shows Choose a folder / Drive / Add a link, and previously linked local folders are still listed and working
Result: there is no way to link a local folder (dynamic, living-file context) to any newly created project — only static uploads/imports.
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
Pre-merge Claude Desktop build (working as of July 7, 2026)
Claude Code Version
1.20186.1 (df1d8a)
Platform
Other
Operating System
macOS
Terminal/Shell
Other
Additional Information
Note on scope: This is a Claude Desktop (Cowork) issue, not the Claude Code CLI — filed here because Cowork/desktop regressions from the same rollout are tracked in this repo with the area:cowork / area:desktop labels (e.g. #76604, #76254, #76344, #76573). The "Claude Code Version" field below therefore contains the Claude Desktop app version.
Screenshots: two attached above in "What's Wrong?" — (1) a pre-merge project's Context "+" menu showing "Choose a folder", (2) a post-merge new project's Context "+" menu showing the upload-only Chat-style options.
Documentation reference: the Claude Help Center article "Organize your tasks with projects in Claude Cowork" still documents "Use an existing folder on your computer" as a context option for projects.
Showing cached comments. Read the full discussion on GitHub ↗
7 Comments
Given #76694's note that this rollout was a Chat/Cowork merge and that session-level folder grants aren't persisted as project context, the cloud-vs-local divergence above may be a symptom of grants no longer propagating to the cloud session path — consistent with the sibling regressions in #76344 and #76604. Check my comment on #76254
This also has broken the folder relationship for my active CoWork projects - they no longer have access to the approved folders that they were built upon
Folder access disappeared today in the cowork. It was functional after the new Project and Chat ui change, but stopped working this morning. (mac os)
I can continue working by creating a new cowork session and adding the project and folder to it. This seems to work for my preflight checks and smoke test. (For now, this is a functional workaround)
Environment: Claude Desktop macOS version , post-merge build, as of July 24, 2026.
Observed:
Project created today via Cowork "+" → "Use an existing folder" successfully bound a local folder. Shows the folder path and a "Local" badge in the Projects list.
Project created July 8, 2026 (merge window) has no folder binding and the Context panel offers no "Choose a folder" option. Only the Chat-style knowledge menu (file uploads, pasted text, imports).
This inverts the report above. In my case the newly created project retains folder linking and the older one cannot acquire it, rather than pre-merge projects being grandfathered in.
Likely factor: creation path, not creation date. My working project was created through "Use an existing folder," which binds the folder at creation. The July 8 project appears to be Chat-origin, surfaced in the unified Projects list post-merge, and there is no path to convert it or attach a folder after the fact.
Requested behavior: Context panel on any project should offer "Choose a folder" post-creation, per the documented behavior at https://claude.com/docs/cowork/guide/projects ("You can attach more folders, links, or projects from Chat at any time from the project's settings"). Current UI does not match the docs for these projects.
Impact: Existing projects with accumulated instructions and history cannot gain live folder context without being rebuilt from scratch. In-session "Add folder" works but is not persisted, so it is not a substitute for recurring work.
Ι m a notary public (max user) and this issue directly impacts my daily workflow.
Before the merge, I used Cowork projects with "Choose a folder" to draft legal deeds. My setup:
Claude read files from the local folder on demand without filling the context window. This was critical because my templates alone are extensive, and each case folder contains multiple legal documents.
After the merge, the static upload approach loads everything into the context window at once, which fills up quickly and degrades output quality — especially for complex property transactions requiring multiple templates + case data simultaneously.
Current workaround: I bypass the project system entirely and point Claude to a local folder structure manually each session, asking it to read files on demand. This works but loses the persistence and convenience of the old project setup and it is clearly a regression.
What I need restored: Dynamic, living-file context via "Choose a folder" in new projects — not static uploads. The distinction between on-demand file reading vs. front-loading everything into context is the difference between a usable and unusable workflow for document-heavy professional use cases.
Please prioritize restoring this functionality. Happy to provide more details about the workflow if helpful.
I made a Cowork project after the July merge, and it only ever gave me the plain upload option for adding a reference file, not the old folder-linking one. I uploaded a file with some notes I wanted future sessions to build on, and it just never actually loads into the project - I checked the app's diagnostic logs and every single sync attempt says it found the file but downloaded and saved none of it. This has repeatedly happened, even after signing out and back in, turning my VPN off, and clearing the app's cache. Claude keeps forgetting things that I have invested significant time/resources already establishing and often contradicts earlier correct answers, apparently because it's not actually able to see the notes file unless I explicitly tell it to go check for it. It is a hassle to have to repeatedly ask Claude "did you read the instructions and project context?" I also found the same "requested project was not found" error in my logs that's mentioned in the related issue about disappearing projects, so it may be the same root cause. I reported this through the Anthropic website with logs attached, but that process was a bit cryptic.