[BUG] Cowork: new projects lost "Choose a folder" — Context menu replaced with Chat-style upload-only knowledge menu after Chat/Cowork merge

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:

• Project knowledge: drafting templates, glossary, and conventions (reusable across all cases)
• Linked local folder: case-specific documents (prior deeds, title chains, client data)

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.

"Same issue on Windows — adding field evidence and a related inconsistency:"

Cowork — Project ↔ Folder Context Regression: Bug Report & Feedback

Reporter: Paid Cowork subscriber (professional folder-centric workflow)
Date: August 2026
Product: Claude Desktop — Cowork (Projects)
Build context: post Chat/Cowork merge (rollout ~July 8–9, 2026)
Primary related issue: anthropics/claude-code #76694 (open)

---

1. Summary

Since the Chat/Cowork merge, linking a local computer folder as living project context — the core Cowork workflow — has become inconsistent and, on the affected projects, unavailable. The Context "+" menu now differs from one project to another with no documented or predictable rule, and there is no way to add, change, or remove the working folder on the affected projects. Static file uploads (the only option offered on those projects) are a one-time snapshot, not a live folder Claude can read updated files from or write back to.

For a paid, folder-centric workflow, this is a regression below the pre-merge product.

---

2. Environment

• Claude Desktop, post-merge build (auto-updated during the ~July 8–9, 2026 rollout)
• Projects feature (Cowork), model shown as Opus 4.8
• Multiple projects, each with its own Instructions and Memory; some connected to folders before the merge, some created after

---

3. Core regression (confirmed against #76694)

On affected projects, the Context "+" menu offers only static context:
Upload from device / Add text content / GitHub / Drive.
The "Choose a folder" option is absent. Static uploads are a snapshot — they are not a live folder that sessions can read (updated files) or write to.

This matches the open, bug-labeled Issue #76694, and contradicts the still-published Help Center article "Organize your tasks with projects in Claude Cowork," which documents "use an existing folder on your computer" as a project context option.

---

4. Field observations (reproducible; screenshots available privately)

Direct comparison of two projects, each with Instructions and Memory configured:

| Project | Context "+" menu | Folder linking |
|---|---|---|
| Project A | Choose a folder / Drive / Add a link | Works — folders listed in Context |
| Project B | Upload from device / Add text content / GitHub / Drive | Missing — no folder option |

Observed correlation (reproduced across multiple projects):

• Projects that already auto-connected to their working folder now no longer allow adding whole folders — only individual files.
• Projects that did not auto-connect do still show "Choose a folder."

Net effect / why this is worse than a simple missing button: the projects that are built around a working folder (the ones that most need folder management) are precisely the ones that can no longer manage it, while identical-looking projects behave differently with no rule the user can see or rely on. The inconsistency itself is a defect, independent of the missing option.

---

5. Additional confirmed limitations from the same rollout

• Cannot remove a project's original / auto-attached folder from Context — no remove control (#76573, #40043).
• Connected folders no longer writable-mounted into the workspace after the mandatory write-consent change (#76344).
• Project metadata / history lost between sessions; projects disappearing within ~24h; connector tools not reaching Cowork sessions (#76604, #45076, #56484).
• Trusted-folder validation rejecting previously-accepted folders (#76254).

---

6. Business impact

The reporter uses Cowork professionally in a document-heavy estimating workflow. Projects are organized around local working folders containing spreadsheets, PDF plans, and reference templates. The value of the subscription for this use case is a persistent project ↔ folder link that every session reads and writes.

With that broken:

• Work cannot be reliably continued across sessions.
• Files produced in a session are not tied back to the project's folder.
• The only workaround — per-session "Add folder" — must be repeated in every new chat and is not persisted at the project level.

Result: the paid Cowork workflow currently performs below the pre-merge product for folder-centric professional use.

---

7. Requests to Anthropic

1. Restore "Choose a folder" as a project-level Context option on all projects (new and existing), consistent with the published Help Center documentation.
2. Make folder-linking behavior consistent and documented across projects; eliminate the current unpredictable per-project variation.
3. Provide a control to add, change, AND remove a project's linked folder (addresses #76573 / #40043).
4. Restore writable mounting of connected folders (#76344).
5. Fix project / metadata / history persistence (#76604 / #45076 / #56484).
6. Given this is a paid-workflow regression, communicate a status / ETA to affected Cowork subscribers.

---

8. References

• #76694 — "Choose a folder" missing on affected projects (primary)
• #76573, #40043 — cannot remove folder from project context
• #76344 — connected folders not writable-mounted
• #76604, #45076, #56484 — project / data loss between sessions
• #76254 — trusted-folder validation rejecting accepted folders
• Help Center — "Organize your tasks with projects in Claude Cowork"

Attachments: two screenshots available on request — (1) Project A Context menu with "Choose a folder"; (2) Project B Context menu without it (upload-only). Blur client names and file paths before sharing in any public channel.

Windows field report, and I think a more specific mechanism than the reports above.

Environment: Claude Desktop on Windows, post-merge build, tested 2026-08-13. Cowork
project created 2026-07-08 (inside the rollout window) via "Start from scratch", so Cowork
created the project folder itself. Folder sits on a OneDrive-synced local path. Project is
not badged "Local" and its files appear in the right-hand panel as a flat list under
"Claude Projects" rather than as a folder under Context.

Finding: the composer folder selector pre-displays a selection that is never applied.

In a fresh chat the selector already shows the project folder as the active choice, and the
agent-visible session context asserts a folder is selected, names the correct absolute path,
and even names the correct sandbox mount point. Nothing is mounted. Listing the sandbox mount
root returns only the internal directories (project cache, outputs, uploads); the project
folder is absent. The displayed selection is a label, not an applied grant.

Repro (two fresh chats in the same project, nothing else changed):

1. Open the folder dropdown and explicitly re-pick the already-displayed project folder,

then ask the agent to list the project directory. Result: correct full tree.

1. Open a chat, type nothing but the same question. Result: agent reports no folder connected

and describes the project knowledge cache (memory.md, metadata.json) instead.

So an explicit pick applies the mount; the pre-displayed default does not. The selection does
not persist across chats.

Control, which rules out the sync-path theories: a second project in the same OneDrive
tenant, created manually by binding an existing folder and badged "Local", mounts correctly in
fresh chats with no interaction. Same machine, same OneDrive, same build. The difference tracks
how the folder was bound, not where it lives. (For reference, #68954 was closed as a changed
folder path; that is not this. The path here is unchanged and correct.)

Why this is worse than a missing button: the failure is silent and produces confidently
wrong answers. Asked to list the project, the agent does not error; it reports the folder as
empty or absent, because the project knowledge cache it can still read is legitimately empty.
That is indistinguishable from data loss from the user's side. In my case it took several
exchanges to establish that nothing had actually been lost from the folder.

Secondary observations:

• The Context "+" menu on this project offers only `Add files or photos / Skills / Connectors /

Add plugins`, i.e. no folder option, consistent with the original report.

• A third project (manually created, badged "Local") shows a different fault: several chats

display no project context at all, and file cards in those chats open an empty viewer
reporting that the file could not be found. Possibly related to #76604 / #76254.

Workarounds: pick the folder from the composer dropdown before sending the first message of
every chat, or have the agent call the folder-request tool with the explicit path (one approval
prompt, worked first try). Neither persists at project level.

Suggested fixes, in priority order: (1) apply the pre-displayed selection, or stop
displaying it as selected; (2) stop reporting a folder as connected in session context when no
mount exists, so the failure is loud rather than silent; (3) persist the selection at project
level.

Confirming this on Claude Desktop (macOS), current build as of 13 Aug 2026.

Symptom: In a post-merge project, the Context "+" menu offers only: Upload from device, Add text content, GitHub, Figma. There is no "Choose a folder" and no option to link another project as reference context. This is identical whether the composer toggle is set to Chat or Cowork — switching to Cowork mode does not change the Context menu.

What's been lost: Pre-merge Cowork projects had a Context section that accepted (a) a live local folder and (b) a linked project from Chat. Both are gone for newly created projects. My pre-merge project retains its attached local folder and shows the old menu, consistent with the grandfathering described in this issue.

Impact on my workflow: I run several related projects (a strategy project, a cross-sell project, a metrics project) that share source material. Pre-merge I could link them so one project could draw on another's knowledge without duplicating files. Now the only way to share context between projects is to re-upload the same documents into each one, which means every update has to be applied in N places and they silently drift out of sync. Static re-uploads also can't replace a live folder link — the whole value was that the context stayed current.

Net effect: for multi-project work this is a clear regression from the pre-merge experience. The merge simplified the project list but removed the two context sources that made Cowork projects worth using over plain chat projects.

Requested: restore "Choose a folder" and project-to-project linking in the Context menu for projects created after the merge. If the unified model intends to replace these with something else, it would help to document what that path is — the current docs still describe "Projects from Chat" as an available Context option, which no longer matches the app.

+1 same issue

confirming this issue is still present on Version 1.46388.4 (50e62f). windows. i am dead in the water until this resolved.

Reproduced on Windows 11 Pro (Claude Desktop / Cowork).

Projects created after the Chat/Cowork merge show the upload-only Context menu (files, text, GitHub, Drive, Notion) with no "Choose a folder" option. A pre-merge project on the same install still has the old folder-linking Context, so the capability is present but missing from the new-project flow, matching the regression described here.

One detail that may help triage: choosing a single folder at project creation still works, including a drive root, and everything beneath it is in scope. So a high-level folder picked at creation is a partial way round the missing multi-folder Context. What is not possible is adding or changing a folder on an already-created post-merge project.

We're hitting this too, and it's more than an inconvenience for our use case: we're a small agency running one Cowork project per client, deliberately keeping each client's folder isolated from the others (plus a separate "no-AI" folder per client that never gets connected at all, for sensitive data). That isolation depended entirely on project-level folder linking being persistent and multi-folder. Also we use a central folder for overall project rules, information about our setup, tools etc., which has to be connected to every project.

With new projects now limited to a single folder at creation and no way to persist additional linked folders, our only options are (a) mount a shared parent folder — which breaks the isolation we specifically built the multi-folder setup to guarantee, or (b) manually re-add each folder via the in-session folder picker every single chat, which isn't persisted and has to be repeated indefinitely.

Please bring back persistent multi-folder linking at the project level for newly created projects — it's a hard requirement for anyone using Cowork to separate client/tenant data rather than just organizing personal files.

+1

Same, also an agency, we have a folder per client and a combined folder for overall project rules (our brand, tone of voice etc) and this setup is now broken.

Same issue since yesterday. Any insights from Anthropic regarding the fact it is considered as a "bug"?

Still reproducing on Claude Desktop 1.49585.0 (macOS, arm64, Electron 44.2.0), two months after this was filed.

New project created September 2026. During project creation I linked a local folder, which the project page shows under "Folder" as connected on this computer. The project runs Cowork sessions normally and that folder mounts fine.

The problem is that the folder link is now a one-shot, set at creation:

• Context "+" offers only Upload from device, Add text content, GitHub, Drive, Notion. There is no "Choose a folder".
• The "Folder" section listing the folder is display only. No control to add a second folder, and none to change or remove the one that is there (matches #76573).
• On the same machine and the same build, projects I created before the July merge still show the old folder menu and still hold more than one linked folder. So this tracks the project's creation date, not the app version.

Impact:

1. Any project that needs to read from two locations cannot be built at all in the new format. My case is a project folder plus a shared reference folder that several projects consume read-only.
2. There is no migration path. Re-creating a pre-merge multi-folder project in the current format drops its extra folders and they cannot be re-added, so older projects have to be preserved as-is indefinitely.
3. The session-level "Add folder" button is not a substitute. That grant lasts for the session, so every new session on the project starts without the second folder and the project instructions cannot rely on it being there.

Related: #86647 has sessions reporting zero connected folders while the project UI still shows the folder chip, with writes silently falling back to browser downloads. Same area, and together they make project folder state hard to trust.

What would resolve it: restore "Choose a folder" in the Context menu for projects created after the merge, and make the Folder section support add, change and remove.

Still present on Windows in 1.49585.0, two months after the rollout, with a variant not yet described.

Windows 11 (build 26200), Claude Desktop 1.49585.0. In a project created after the merge, the Context "+" menu offers only Upload from device / Add text content / GitHub / Drive / Notion, and the empty state carries Chat's copy ("Add PDFs, docs or other text as reference for this project"). No "Choose a folder".

The variant: this project does have one local folder linked, shown in a separate "Folder" block underneath Context, bound when the project was created. So folder linking is not absent on new projects. What is absent is any way to add a second folder. Pre-merge projects on the same account still hold two linked folders each and continue to work.

Distinct from #76894, where the Add folder button exists but is greyed out. Here there is no such control at all.

Environment: Windows 11 Home 26200, Claude Desktop 1.49585.0, project created on September 9th 2026

Windows, still present on 1.49585.0 (Electron 44.2.0), with a partial change since the original report.

Pre-merge projects: Context panel still lists several locally linked folders, working.

New projects created since the merge: I can attach one folder at project level, but there is no way to add a second — the multi-folder Context list from pre-merge projects is not available. So Choose a folder is not entirely absent here as in the original report; folder linking appears partly restored while multi-folder linking is not.

Attempting to create a Cowork project produces a Chat-style project with the upload/knowledge Context menu and a single folder.

Additional folders can still be attached per session via the device bridge (connectedFolders confirms the mount works), but this is not persisted as project context and has to be redone every session.

Impact: our project pattern is one project folder plus one or more shared method/skills folders linked at project level. That pattern cannot be created on current builds; only grandfathered projects still have it.

Environment: Windows, Claude Desktop 1.49585.0, Electron 44.2.0, Node 24.20.0.

This issue is still labelled platform:macos only, but the thread carries Windows reports from suescumjaramillo (August), ThWiNova (13 August), songokussm (1.46388.4), max1000000 (Windows 11 Pro), FFGFelice (1.49585.0, Windows 11) and me (1.49585.0). Could platform:windows be added — a triage queue filtered by platform would not surface any of them.

bug is still present in today's update: Version 1.52386.0 (1003ca) Sep 9, 2026, 10:55 PM. windows 11. uninstalling and reinstalling does not resolve.

Same here on macOS, Claude Desktop [Claude 1.52386.3 (41896e) 2026-09-11. Confirming the partial-restoration
behavior described above: a new project accepts one folder, but there is no way to add
a second — after that, the Context "+" only offers file uploads.

Use case, in case it helps prioritization: I run a law practice. The setup is one folder
holding a normative corpus (57 plain-text files — procedural and substantive codes,
statutes and collective agreements, ~6 MB total) plus one folder per court case. While
working on a case file, the assistant reads specific articles from the corpus on demand.
That pattern needs two linked folders per project.

Pre-merge projects still work. New ones cannot reproduce it: I have to choose between
the corpus and the case file. Uploading the corpus as static files is not a substitute —
the two procedural codes alone are 1.6 MB, and the whole point of the folder link was
on-demand reading instead of loading everything into context up front.

In-session "add folder" works, but it has to be repeated every session, so it does not
hold as project configuration.

macOS, Claude Desktop 1.52386.6 — still reproducing two months on. Rather than repeat the reports above, one dimension I haven't seen quantified here.

Several comments note that the session-level folder grant isn't persisted. The sharper consequence is scheduled tasks. Across 600 local session records on this machine (2026-07-01 → 2026-09-13), 116 were scheduled-task runs. All 116 ran in pre-merge multi-folder projects, and all 116 loaded more than one folder. Not one has ever run in a post-merge single-folder project. A per-session picker cannot cover an unattended 23:47 job — there is nobody there to click it.

So the grandfathered projects aren't just a nicer workflow; for anyone with scheduled tasks they are load-bearing, and switching the legacy type off breaks those jobs silently rather than visibly.

Full evidence, including the spaceId vs userSelectedProjectUuids split in the local session JSON that cleanly separates the two project types, is in #92710 — that field pair may be a useful triage handle.

Also +1 to @ThomasKirke's request for a platform:windows label; the thread carries at least six Windows reports.

Same thing here, on two separate Macs.

Every project I have created since the merge shows the Chat knowledge menu
under Context: Upload from device, Add text content, GitHub, Drive, Notion.
There is no "Choose a folder." The projects I created before the merge still
have it. I have repeated this across several new projects on both machines, so
this is not something local to one install.

We run a folder per client, plus our own working folder that holds a document
index, build scripts and finished deliverables. A project used to hold both,
and every task inherited them. Now a project takes one folder at creation, and
there is no way to add a second, change it, or remove it later. Any work that
touches a client folder and our own folder at the same time cannot be set up as
a project anymore.

Adding the folder at session level does not fix it. I have to do it again in
every new task, for every client, and a folder added that way never becomes
project context.

Someone will point at the Google Drive connector. It does not cover this. The
connector reads and searches fine. Our index is built and queried with a shell
over an extracted text mirror, and our publish step copies files with
timestamps preserved so drift detection works. A connector upload writes a new
file with a new modification time, and then every published file reports as
drifted. Those are filesystem operations.

What needs to change, in order:

1. Let folders be added and removed from a project's Context after the project

exists.

1. Let a project hold more than one folder.
2. Give projects created after the merge the same Context menu the older ones

kept.

The help centre article on Cowork projects also still describes the old behaviour
and says the Context section is where you "Add a local folder." That sent me
hunting for a control that is not there, and it makes this look like user
error.

bug is still present in today's update: Version 1.52386.6 (612f3f), windows 11. any ideas how to get visibility on this? its quite the show stopper.

A workaround, in https://claude.ai dev console:

(async () => {
  const org = org-uuid;
  const proj = 'proj-uuid';
  const base = `/api/organizations/${org}/projects/${proj}`;
  const p = await (await fetch(base)).json();
  const b = p.cowork_bound_device;
  console.log('current', JSON.stringify(b, null, 2));
  if (!b || b.migration_status !== 'complete') { console.log('ABORT: unexpected binding'); return; }
  const folders = [...new Set([...b.folders,
    '/new/path/to/add'])];
  const r = await fetch(`${base}/settings`, { method: 'PUT',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ cowork_bound_device: { ...b, folders } }) });
  console.log(r.status, JSON.stringify(await r.json(), null, 2));
})();

anyway to modify this for cowork?

Adding a concrete case, since the thread is mostly reproduction steps.

I run an independent consulting practice and use Cowork as the operating layer for it. The setup requires eight folders linked to one project at once: the active project folder, a shared workspace folder, a master contact database, two marketing folders, an admin folder, a meeting-notes folder synced from Drive, and a local scratch folder. These are not conveniences. A single run reads a contact list from one folder, drafting rules from another, and writes output back to a third.

Pre-merge that worked. Post-merge I get one folder at project creation and no way to add a second. The Context "+" menu offers Upload from device / Add text content / GitHub / Drive / Notion, and the folder section is display-only – no add, no change, no remove.

The session-level "Add folder" bridge is not a substitute, for two reasons. First, I re-add eight folders at the start of every session before any work can happen. Second, and worse, a missing mount fails silently. I have had a scheduled task run to completion with a folder unmounted and produce nothing, with no error anywhere. A hard failure would at least be visible.

Confirming it is still present on macOS: Claude desktop app 2.2553.1 (Electron 44.2.0), macOS on Apple Silicon.

What would fix this: "Choose a folder" restored to the Context menu on new projects, multiple folders per project, and add/change/remove controls on the folder section.

This is my workaround as an agency using a folder per client with supporting shared folder.

Claude project is set to the primary client folder /Clients/Client Name

Then I give claude instructions to reference the other folders via the Google Drive connector (or Composio). It tells it what is in what folders and when to use them.

It's not as seamless as the old way but it works. I suspect with the changes we saw last week with office apps and consolidating chat & cowork that anthropic are moving towards a simpler implementation and I won't be holding my breath. It feels like this was a choice rather than a bug, either way it would be nice if they told us (this is how it is now or we are working on bringing them back).

Confirming this also breaks EXISTING (pre-merge) projects, not just new ones.

Environment

• Claude Desktop [version/build], Windows [10/11]
• Plan: [Pro/Max/Team]

What happened

1. I have a pre-merge Cowork project with multiple local folders linked in Context (primary + secondary).
2. I needed to change the secondary folder, so I removed it from the project's Context.
3. There is now no way to add a folder back. The Context menu offers only [list what you see, e.g. Upload from device / Add text content / GitHub / Drive / Notion]. No "Add folder" / "Choose a folder".
4. The project is now permanently single-folder. There was no warning on removal that this was irreversible.

Impact

• Scheduled tasks in this project depend on both folders. Per-session "Add folder" is not persisted on the project and does not apply to scheduled runs, so the automation is broken with no in-product way to restore it.
• The Help Center article "Organize your tasks with projects in Claude Cowork" still documents "Add a local folder" under Context.

Asks

1. Is removal of multi-folder project context a bug or an intended change?
2. If intended: restore a way to persist multiple folders per project (or per scheduled task), and update the docs.
3. Regardless: the remove-folder control on legacy projects should warn that the action cannot be undone, or be disabled, until re-adding is possible.

found a workaround.

Claude App:

1. Profile
2. Settings
3. Cowork
4. Trusted Cowork Folders
5. Manage
6. Add the folders you want to access

Per Project Instructions

1. Before any other action, read <path>.

• Replace <path> with the path to your secondary files.

1. If access is blocked, request access to the folder, then retry.
2. If access is still blocked, reply exactly <name> missing. and stop.

• Replace <name> with a short name that makes sense for the file or folder.

What this does:
It causes claude to prompt you to grant access to the files/folder in item 1.
One button click to allow.
Using 'Add Folder' every session, takes three clicks, per folder.
This also works with multiple folders. One click per folder.

Thanks for reply

Thanks,
RN

• Please excuse typos and brevity, sent from my mobile.

________________________________
From: songokussm @.*>
Sent: Tuesday, 22 September 2026 16:15:12
To: anthropics/claude-code @.*>
Cc: Ron Norman @.>; Comment @.>
Subject: Re: [anthropics/claude-code] [BUG] Cowork: new projects lost "Choose a folder" — Context menu replaced with Chat-style upload-only knowledge menu after Chat/Cowork merge (Issue #76694)

[https://avatars.githubusercontent.com/u/115196224?s=20&v=4]songokussm left a comment (anthropics/claude-code#76694)<https://github.com/anthropics/claude-code/issues/76694#issuecomment-5785076438>

found a workaround.

Claude App:

1. Profile
2. Settings
3. Cowork
4. Trusted Cowork Folders
5. Manage
6. Add the folders you want to access

Per Project Instructions

1. Before any other action, read <path>.

• Replace <path> with the path to your secondary files.

1. If access is blocked, request access to the folder, then retry.
2. If access is still blocked, reply exactly <name> missing. and stop.

• Replace <name> with a short name that makes sense for the file or folder.

What this does:
It causes claude to prompt you to grant access to the files/folder in item 1.
One button click to allow.
Using 'Add Folder' every session, takes three clicks, per folder.
This also works with multiple folders. One click per folder.

—
Reply to this email directly, view it on GitHub<https://github.com/anthropics/claude-code/issues/76694?email_source=notifications&email_token=AU2NW2CPYVERPXHLY66MKMT5QL2XBA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNZYGUYDONRUGM4KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5785076438>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AU2NW2EYJ5ZIWDYSUXI6PNT5QL2XBAVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TIOBWGI4DQNBUHAZ2C5QC>.
You are receiving this because you commented.Message ID: @.***>

Resolved on my install (macOS), as of 25 September 2026.

A project I created today shows a Folder block in the Context panel with a + control, and it accepts more than one local folder at project level. I currently have projects with two and with four folders linked.

What I verified:

• Added a second folder to a project created on 25/09/2026 — not a grandfathered pre-merge project.
• Opened a new conversation in that project: both folders were mounted from the first message, with no permission prompt.
• Quit the app (Cmd+Q) and rebooted the machine. The links persisted, and a new conversation again started with both folders mounted and readable.
• The Folder section is no longer display-only: folders can be added after the project has been created.

So on this build the "one-shot at creation" behaviour and the missing add control described above are gone.

App version: 2.9939.2 (d3e504), built 24 Sep 2026 — macOS (Darwin 25.6.0).

I can't tell whether this is a staged rollout or a full fix, and I haven't tested on Windows, so the Windows reports above may still be current.

One note for anyone still blocked: the per-project instruction workaround posted earlier still works, and it is worth keeping even after the fix. A folder can show as linked in the UI and still not mount (see #86647) — I hit exactly that today, on a folder whose name had a trailing space: the chip was there and the session saw an empty folder. An instruction that makes the session verify the mount and say so, instead of treating an unmounted folder as empty, is useful regardless of this bug.

fixed!
Version 2.9939.2 (d3e504)
Sep 24, 2026, 10:20 AM
Windows.

Version 2.19675.0 (5706e5)
Sep 30, 2026, 10:47 PM
windows.

broke it. the projects list the folders connected, but when you actually start a session, only the first folder is actually connected. prompting to connect folders no longer works.

Still reproducible on Windows 11, Claude Desktop 2.31226.1.

Steps: New project → no option to bind an existing local folder. Adding the folder per task works, but it is not saved to the project, so every new task starts without my workspace.

Why it matters: project = local folder was the core advantage of Cowork for me. My folder holds CLAUDE.md, reference files, and outputs, managed in Obsidian. Without a persistent binding, a project is just a chat label.

Request: restore persistent folder binding for projects, and please add the platform:windows label.