[BUG] Cowork "one home" merge makes local Cowork projects unreachable when cloud chats/projects are disabled (macOS)
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
The July 7, 2026 change that merged Chat and Cowork into "one home … with one place for your projects and artifacts across both" removed the standalone Cowork tab and re-routed all access to Cowork projects and chats through the unified cloud-backed home.
For users who have opted out of cloud chats and projects — a deliberate, supported setting (my reason below) — there is no longer any UI path to my Cowork projects at all. The projects still exist (verified on local disk), but every surface that would open them is gated behind the cloud chats/projects feature I turned off. Cowork, for a local-only user, is effectively unusable after this update. This is not a cosmetic layout complaint: the merge coupled a core capability (access to my own Cowork work) to an optional cloud feature.
Why I had cloud chats/projects disabled, and the stronger general argument
To be precise rather than overstate it: I disabled cloud chats/projects for a workflow reason, not a compliance mandate. Before this merge, cloud chats did not translate into Cowork — a separate surface Cowork couldn't use — so I kept chats local and worked in Cowork's own space. This was a deliberate change I made to adopt Anthropic's model: coming from OpenAI, cloud chats were directly usable in Codex and there was no Cowork, so I restructured my workflow around Cowork as the primary local surface. The "one home" merge pulls the rug on exactly that adopted workflow.
Separately — and this is the stronger, more general reason the coupling is a defect — the same behavior breaks Cowork for privacy- and compliance-driven users who must keep cloud sync off by policy (healthcare/PHI, proprietary IP, enterprise data governance). My motivation was workflow continuity; theirs is data governance. Either way: access to local Cowork data must not depend on enabling cloud chats/projects.
Not a duplicate of the "missing tab" packaging regressions
Please don't close this as a duplicate of the earlier tab-missing reports (#60125, #49428 and the Windows equivalents). Those are a build/packaging regression — the Cowork runtime absent from the app bundle. This is the opposite and a distinct root cause: the runtime is present and healthy, and the tab is gone by design via the July 7 merge. The defect is that the merge coupled access to local Cowork data to the cloud chats/projects feature, so opting out of cloud sync hides local content. Related to but broader than #18818 (keyboard shortcuts) which is ergonomics, not data access. See also #76143 and #77682.
Environment
- macOS (Apple Silicon), Claude Desktop
- Observed on builds 1.21459.3 and 1.18286.0 (rolling the binary back did not help — the UI is served remotely, so the merged layout applies regardless of installed version)
- Account: personal Max plan, billing current; same behavior under a Cowork-entitled Team org
- Relevant setting: cloud chats and projects — opted out
- Local state present: 32 persisted Cowork sessions on disk under ~/Library/Application Support/Claude/local-agent-mode-sessions/, loading successfully per main.log. Runtime initializes normally; the data exists but the UI will not surface it.
Steps to reproduce
- Use Cowork, accumulating local projects/sessions.
- Opt out of cloud chats and projects (keep local only).
- Update to a build on/after the July 7, 2026 "one home" merge.
- Open the app and try to find/open existing Cowork projects.
Actual behavior
- With cloud chats/projects opted out, the unified home shows no Cowork projects or chats. The projects home is the only entry point and it is empty because it is populated from the cloud feature I disabled.
- No separate Cowork tab, no alternative local entry point. My 32 on-disk sessions are orphaned by the UI.
Impact / severity
- Cowork is unusable for local-only users; existing work is inaccessible through the product though intact on disk.
- Hits regulated/security-sensitive users who opt out of cloud sync by policy — the users with the strongest reason to run a local agent.
- Also hits workflow-continuity users who disabled cloud chats because, pre-merge, they did not carry into Cowork.
- Forced choice: enable cloud sync of sensitive chats/projects, or lose access to your own local Cowork work. The previous UI required neither.
What Should Happen?
Expected
- My existing Cowork projects and chats remain browsable and openable in the app, independent of whether cloud chats/projects sync is enabled.
- Opting out of cloud sync should affect where data is stored/synced, not whether I can see my own locally-stored work.
Requested fixes (priority order)
- Decouple Cowork project/chat access from the cloud chats/projects feature. Locally-stored Cowork sessions must be browsable and openable regardless of the cloud-sync opt-out. (Core defect.)
- Provide a persistent, local-independent Cowork entry point — restore the separate Cowork tab, or a "classic layout" opt-out that keeps Cowork as its own surface rather than a composer selector inside the cloud home.
- Guarantee that opting out of cloud sync never hides on-disk data. Treat cloud opt-out as a storage/sync boundary, not a visibility gate on local content.
- Add direct navigation / keyboard shortcuts between Chat, Cowork, Code, and Conversations (see #18818).
One-line ask: make Cowork's own projects and chats reachable without requiring cloud chats/projects to be enabled, and give local-first users a way back to a dedicated Cowork surface.
Error Messages/Logs
From the desktop app main.log on launch (paths trimmed) — the runtime initializes and loads all 32 local sessions the UI will not surface:
[WarmLifecycle:cowork] Initialized (arm=always)
[compliance] coworkHipaaRestricted at app-ready: unrestricted
[CoworkFilePreview] Protocol handler registered
Loaded 32 persisted sessions from .../local-agent-mode-sessions/<account-uuid>/<workspace-uuid>
Steps to Reproduce
- On Claude Desktop (macOS), have existing Cowork projects/sessions that were created and used before the July 7–8, 2026 Chat/Cowork "one home" merge.
- In settings, opt out of cloud chats and projects (keep chats/projects local only).
- After the merge has rolled out to the account, open the app (or claude.ai) and go to the unified Chat/Cowork home.
- Look for your existing Cowork projects/chats in the Projects/home list — they are absent. The projects home is populated from the cloud chats/projects feature, which is off, so nothing appears, even though the sessions load locally (main.log: "Loaded 32 persisted sessions …") and the files exist on disk under ~/Library/Application Support/Claude/local-agent-mode-sessions/.
- Isolating step: re-enable cloud chats/projects and the projects become reachable again — confirming access is gated on the cloud feature, not on whether the local data exists.
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
Before the July 7–8, 2026 Chat/Cowork "one home" merge rolled out to the account (the standalone Cowork-tab era).
Claude Code Version
N/A — this is the Claude Desktop app (merged Chat/Cowork UI), not the Claude Code CLI. Desktop build 1.21459.3 (also reproduced on 1.18286.0).
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
This is a Claude Desktop (Cowork) issue, not a Claude Code CLI issue — please route/label accordingly rather than auto-closing as invalid.
Related merge-fallout reports (distinct symptoms, same July 7–8 "one home" merge): #75603, #76604, #76143, #75625, #76344, and the ergonomics request #18818. This report's specific, isolable root cause — local Cowork projects hidden because cloud chats/projects is opted out — does not appear to be captured in those.
Core ask: decouple access to local Cowork projects/chats from the cloud chats/projects sync setting. Opting out of cloud sync should not hide on-disk local work.