[BUG] [Cowork] Existing local-folder project disappeared after Chat/Cowork web/mobile merge (Jul 8, 2026)
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?
After the Chat/Cowork merge rolled out on web/mobile today (July 8, 2026), a Cowork project that was previously bound to a local folder on Windows disappeared from the Projects list. The project had been working normally before the merge (local folder access, file reads/edits all functioned via a device/computer-use connector).
What Should Happen?
Existing Cowork projects, including their local folder bindings, instructions, and memory, should be preserved through the Chat/Cowork merge rollout, not lost.
Error Messages/Logs
Steps to Reproduce
- Have an existing Cowork project on Claude Desktop (Windows) bound to a local folder (e.g. C:\Users\<user>\Documents\Claude\Projects\<project>), created and used successfully before July 8, 2026.
- 2. Wait for the Chat/Cowork web/mobile merge to roll out on the account (occurred today, Jul 8 2026 - see https://www.anthropic.com/news and in-app changelog).
- 3. Open Claude Desktop or claude.ai and check the Projects list.
- 4. The previously existing local-folder project is no longer listed.
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
Working normally prior to the Jul 8, 2026 Cowork web/mobile merge rollout
Claude Code Version
N/A - reporting via Claude Desktop app (Cowork/Chat merged UI), not Claude Code CLI
Platform
Other
Operating System
Windows
Terminal/Shell
Other
Additional Information
Environment: Windows, Claude Desktop app, project folder under C:\Users\<user>\Documents\Claude\Projects\. Related but separate issue being filed alongside this one: after creating a brand-new project and re-attaching a local folder, folder access also fails even after approving the OS-level folder access permission dialog (device bridge tool not registered in session).
5 Comments
make sure you click on the top right icon and select "Run this task, On your computer" and not "in the cloud"
I don't see such an icon
<img width="1396" height="607" alt="Image" src="https://github.com/user-attachments/assets/00bc82f1-e266-46d0-a739-4ac2bc39e828" />
<img width="1413" height="543" alt="Image" src="https://github.com/user-attachments/assets/baf5b44a-c12a-4ce6-8fca-75c1273fdde8" />
Same failure on macOS, starting July 12 — four days after this report.
Roughly 7 of my 30–40 projects are visible; the rest are gone from the Projects list, along with every Cowork session nested inside a project. Missing on the desktop app, on claude.ai in a browser, and on iOS. Standalone chats are unaffected, and the only two Cowork sessions still visible are the two that belong to no project.
Not an auth issue: I signed in cleanly in a browser and separately on iOS under the correct account. Identical incomplete project list on every surface.
Possible discriminator: the projects still visible are ones where Claude created its own default folder. Every project where I explicitly pointed Claude at a folder I created myself is missing. An older project using a Claude-created folder is still there; newer work on the same matter, pointed at my own folder, is not.
Also seeing the desktop app trapped in new-user onboarding — a Free/Pro/Max plan picker shown to an existing Max subscriber, no Sign Out in the menu, Settings opening to the same screen, app on latest version.
Given #76344, #76604, and #78191 all describe Cowork/local-folder regressions from the same Jul 8 merge, this doesn't look platform-specific and the invalid label may be worth revisiting. Support ticket open since July 12 with no human response.
Update: I resolved the desktop onboarding loop by terminating the desktop session in Account settings and renaming ~/Library/Application Support/Claude. The app then gave a proper Sign In screen and I'm back in.
The missing projects did not come back. Same seven visible, plus the few I created in a browser this week. So the desktop lockout and the project loss are two separate failures — fixing the client changes nothing, which is consistent with this being server-side account state.
RESOLVED on my account (macOS) — full recovery. Posting the exact sequence in case it helps others here.
My symptoms, starting Jul 12 (four days after the merge reached me):
~7 of 30–40 projects visible; the rest gone, along with every Cowork session nested inside a project
Standalone chats and standalone Cowork sessions unaffected
Missing on desktop, claude.ai in a browser, and iOS
Desktop app trapped in new-user onboarding: a Free/Pro/Max plan picker shown to an existing Max subscriber, no Sign Out in the Claude menu, Settings opening to the same screen, app on latest version
A clean re-auth in a browser and a separate clean sign-in on iOS restored nothing
What worked:
In claude.ai → Settings → Account → Active sessions, hover the "Claude Desktop" row and choose Terminate. (This alone did not fix the loop, but it's a clean first step and touches nothing else.)
Quit the desktop app completely.
In Finder, Cmd+Shift+G → ~/Library/Application Support → rename the Claude folder to Claude-old. Do not delete it. This is the critical part.
Reopen the app. It presented a genuine Sign In screen instead of the plan picker. Signed in normally.
At this point the app worked but projects were still missing — the fresh install had built its own empty local-agent-mode-sessions.
Quit the app. In the new ~/Library/Application Support/Claude, rename the freshly created local-agent-mode-sessions to local-agent-mode-sessions-new.
Copy local-agent-mode-sessions from Claude-old into the new Claude folder.
Reopen the app.
Result: all projects back, with their full chat history.
Two things worth flagging for anyone still stuck:
The circulating "fix" for the onboarding loop — delete the contents of ~/Library/Application Support/Claude — would have destroyed the recovery path. The session data lives in local-agent-mode-sessions inside that directory. Rename the parent folder, never delete it, and keep it until you have confirmed recovery.
The corruption was not in local-agent-mode-sessions. That folder was intact and restored cleanly into a fresh install. Whatever wedges the app into onboarding lives elsewhere in that directory. I have the original preserved and can provide it or run diagnostics against it if that would help anyone debugging this.
One correction to my earlier comment: I had assumed this was server-side account state, since the projects were also absent from claude.ai and iOS. That inference was wrong. For local-folder-bound projects the desktop app appears to be the source of truth, and the other surfaces showed nothing because the desktop couldn't surface them either.
Support ticket opened Jul 12; I never received a human response, and resolved this from the community reports in this thread — particularly @jeffepaul's note in #78191 identifying local-agent-mode-sessions as where the persisted sessions live. That pointer is what made the recovery possible.