What's the fundamental difference between a local-folder project and a cloud project?
Why does Cowork let a project bind to a single device instead of making everything cloud-native?
Mechanically, how does this sync limitation actually work?
How does this actually affect day-to-day work for someone using Cowork?
You spend twenty minutes on a Friday afternoon setting up a Cowork Project on your office machine — linking a local folder of financial reports, writing project instructions, running a couple of tasks so Claude picks up on your formatting preferences. Over the weekend you open Claude at home to finish the rest, and the project simply isn't in the list.
That's not a bug. It's a structural difference between the two ways a Cowork Project can be created, and it's a difference almost nobody notices at setup time.
Cowork lets you create a project three ways: from scratch, imported from an existing Claude project, or pointed directly at a folder on your computer. The first two live under your cloud account, so signing into that same account on another machine shows them. The third — linking a local folder — makes that machine the project's home, not your account.
The distinction is about data ownership. When a project points at a local folder, Claude is reading and writing files that physically exist on that machine, which ties the project to that machine's Desktop app. Your account remembers the project exists, but the filesystem path it depends on means nothing on a different computer.
The counterexample is a cloud project: if its context comes from a linked Claude project or a URL rather than a local folder, it's a purely cloud-native object that syncs across devices without issue, mobile included.
The people most likely to hit this are using Cowork as a souped-up folder manager — a common pattern on legal or finance teams: link a local contract library or report folder directly into a Project so Claude learns the file structure and naming conventions. It's an efficient setup, but the cost is that the Project can now only move on that one machine, in that one Desktop app.
Another common scenario: a team shares one "workstation" computer and sets up a local project on it, only to find that whoever isn't physically sitting at that machine can't see the project at all — and mistakes it for a permissions problem.
If cross-device access matters to you, ask at creation time: is this project's core value "a link to files that only exist on one specific machine," or "a set of instructions and memory"? If it's the latter, default to a cloud project and treat local files as a one-off input for a single task, not the project's core context. If you genuinely need live access to a local folder — a financial report that's continuously updated, say — accept that this project is tied to that machine, and make it explicit to the team that "this Project lives on so-and-so's computer" so nobody wastes time hunting for it elsewhere.
One safety net worth knowing: archiving a local-folder project only removes it from the UI — the local files themselves are untouched. So archiving won't accidentally wipe the folder.
Cowork's capabilities are being folded into standard Claude for Pro and Max plans, which means the line between a "Cowork Project" and a regular Claude Project is itself shifting. But whatever the interface looks like afterward, the root cause of "local folders bind to one device" isn't going away — as long as Claude needs to read and write files that physically exist on one machine, that machine has to be present. The practical fix is simple: before you link any local folder, ask whether this project will ever need to be opened from another device. If the answer is yes, put the data in a cloud folder or connector instead of scrambling to fix it the weekend you find the project missing.