I keep catching myself translating.
When I say "the MemoryOS project," I mean one thing. But my tools hear five different things. Claude.ai hears a Project with conversation scope and custom instructions. Claude Cowork hears a Drive-backed workspace. Claude Code hears a disk folder with a CLAUDE.md at its root. My shell hears a git repo with a wrangler.toml and a D1 binding. And Claude in Chrome hears something else entirely — a surface-scoped action context that's here when I'm on the right tab, and gone when I switch.
Five different things. All called "project." All partially true.
This isn't a complaint about Anthropic. The surfaces were built to solve different problems, at different times, by teams with different priorities. The word "project" just happened to be the convenient label five times in a row. That's how product namespaces usually end up — by accretion, not by design.
But if you run five or six Claude surfaces in parallel every day the way I do, the translation tax is real. Let me name the five things explicitly, then talk about what to do.
The five projects
1. The disk-and-git project. Substrate-level truth. A folder on your machine, under version control, with a deployable artifact at the end of it. Git remote, CI pipeline, secrets, live URLs, databases, domains. It can be built and shipped. This is the only project a customer ever actually touches.
2. The Claude.ai Project. A conversation-scoping container. Custom instructions, uploaded knowledge files, a scoped history of chats on a topic. It doesn't know about your disk. It can't deploy anything. What it's good at is remembering what you said about a topic over weeks of conversations, and keeping that context separate from your other work.
3. The Claude Cowork workspace. Drive-backed. Task and file manipulation. Good at "take these three files from my Drive and produce a summary." Not good at generating code you'd check into git. Different primitive, different superpower.
4. The Claude Code project. This one's a trick. It's really just the disk-and-git project wearing a CLAUDE.md hat. The file sits at the root of the folder; Claude Code reads it to know how to behave inside the project. So there's no new project here — there's a governance file attached to an existing one.
5. Claude CLI and Claude in Chrome. Surface-scoped action contexts more than projects. Open Chrome, Claude is there, knows about the tab you're on. Run Claude CLI, it knows about the terminal and the current directory. They can read a project's files if pointed at them, but "project" isn't their native unit. They're transient by design.
Five different things. One word.
Why they can't be unified
The temptation is to flatten all of this into one object. One project that means the same thing everywhere, syncs across surfaces, carries conversation memory and disk state and Drive files and CI config in one canonical place.
I've sketched versions of this several times. Every sketch has ended in the trash.
A Claude.ai Project without a filesystem can't deploy anything. That's not a missing feature — it's the point. It's a conversation container. Add filesystem access and it becomes a different product.
A disk folder without conversation memory can't remember what you said three weeks ago. Disk folders are for artifacts, not dialogue history.
A Cowork workspace that can run wrangler deploy is just a worse IDE. A Claude.ai Project that sees your full disk is a security nightmare.
Each surface is good at one thing because it isn't trying to be the other four. Force them into one object and you lose what each of them does well.
What can be unified
Not the contents. The identity.
Every project I run has a stable identity in my head — "MemoryOS," "Beacon Proxy," "Kurka Labs." The five surfaces each have their own incomplete picture of that identity. What's missing is a single place that says:
"MemoryOS" means this claude.ai Project ID, this Cowork workspace path, this disk folder, this git origin, these live URLs, these databases, these domains.
One manifest per project. Not duplicate state. Just pointers.
Once you have that, the rest is easy. An MCP server that reads the manifest. Every surface that can call MCP gets the unified picture on request. Surfaces that can't call MCP just read the manifest file from Drive directly. Your brain stops translating, because there's an answer of record.
The build is thin — a couple hours of work, most of which is catalog discipline rather than code. The payoff is that "what is project X?" has a single answer instead of five partial ones.
But sometimes the honest answer is no build at all. If your translation tax is diffuse — friction on some days, on different surfaces, for different reasons — the identity manifest itself becomes a new source of friction. It couples things whether you want them coupled today or not. A folder-by-folder PROJECT_REFS.md note, filled in only when useful, might beat the central registry. A manual cross-reference in a README.md might beat both. Don't assume your pain is continuous just because it's real. The right build depends on whether the friction is sharp or diffuse.
The rabbit holes to avoid
Once you start thinking about unification, it's tempting to keep going. Worth naming the traps out loud, because I've walked into most of them.
Don't sync Claude.ai Project knowledge files down from disk. Knowledge files live in claude.ai because you curated them for that conversation context. Auto-syncing from disk fills the Project with noise and blows through file-size limits fast.
Don't bridge Cowork state into Desktop. Cowork and Desktop have different models of what "state" is. Trying to reconcile them produces a mediator layer that's worse than either original.
Don't merge conversation histories across surfaces. The memory mechanisms are fundamentally different — claude.ai Projects have their own, Claude Code uses CLAUDE.md, Desktop uses whatever you've wired up. Bridging them produces confused assistants who don't trust any source.
All three look tempting. None of them solve a top-three pain. The identity manifest does.
The wider pattern
When the same word starts meaning five things, the instinct is to collapse it back to one. Almost always the wrong move. The word is doing five jobs because there are genuinely five jobs to be done. The shared name is a notational convenience, not a design claim.
The right response isn't unification. It's a thin identity layer — one that lets each surface keep being exactly what it's good at, while your brain stops doing translation work.
That's true for "project" across the Claude ecosystem. It's also true for "document," "workspace," "conversation," and a dozen other words that got overloaded as AI tooling exploded sideways over the last two years.
The identity layer is where the leverage lives. The unification layer is where months of engineering go to die.