[BUG] Cowork: Project memory reaches Local sessions but not Cloud sessions — silently, and the docs contradict each other

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?

Project instructions are delivered to Cloud Cowork sessions. Project memory
is not. The session cannot detect the gap, the UI gives no indication, and the
two help articles covering this contradict each other about whether it should
happen at all.

Measured across two machines on identical app versions:

| Platform | Environment | Project | Memory reached session |
|----------|-------------|-----------------------|------------------------|
| macOS | Local | Long-lived | YES (quoted verbatim) |
| macOS | Local | Brand-new empty (ctrl)| none (correct) |
| macOS | Cloud | Long-lived | NO |
| Windows | Cloud | Long-lived | NO |
| Windows | Local | Long-lived | untestable (see below) |

The control (brand-new empty Project on macOS Local returning no memory)
establishes that memory is project-scoped rather than account-scoped, and that
the positive result is genuine rather than the model confabulating.

The delivery is PARTIAL, which is the surprising part. In a Cloud session the
Project's instructions arrive intact and can be reproduced verbatim -- but
project inspection from inside that session returns no memory field at all.
Not an empty one: the key is absent. No memory-reading tool is exposed either.
So the session cannot read memory, cannot detect that memory exists, and cannot
tell the user it is missing.

I am filing this primarily as an OBSERVABILITY and DOCUMENTATION-ACCURACY
issue. If local-only memory is intended, the intended behaviour is currently
undiscoverable -- by the user and by the model alike.

What Should Happen?

Either:

(a) Cloud sessions receive Project memory, matching the unqualified promise in
the help article ("Claude can remember context from tasks you've run in a
project and apply it to future tasks in the same project"); or

(b) if memory is intentionally local-only, the product says so -- at
task-creation time when a Project with a non-empty memory store is opened
in Cloud mode, and to the session itself, so it can compensate by reading
source files instead of silently answering with less context.

Either way, the two help articles should stop contradicting each other.

Error Messages/Logs

No error is produced. That is the substance of this report: the failure is
entirely silent. The session runs normally and simply answers with less
context, giving the user no diagnosable cause.

Steps to Reproduce

Requires a Project with a non-empty Memory panel (mine accumulated over roughly
three months of Cowork use on macOS Local).

1. Open a Project whose Memory panel visibly contains entries.
2. Create a Cowork Task in that Project with the "Local" environment.
3. Ask: "Can you see this Project's memory? If so, quote the first three

entries verbatim."
-> The session quotes them. Cross-check against the Memory panel: they match.

1. Create another Cowork Task in the SAME Project, this time with the "Cloud"

environment.

1. Ask the identical question.

-> The session reports it has no memory. Project instructions, however, are
present and can be reproduced verbatim.

1. Repeat step 4-5 on a second machine (I used Windows). Same result: no memory.

CONTROL (rules out account-scoped memory and model confabulation):

1. Create a brand-new empty Project. Create a Local Cowork Task in it and ask

the same question.
-> No memory, as expected. Confirms memory is project-scoped, and that the
positive result in step 3 was genuine.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

1.34493.1

Platform

Anthropic API

Operating System

Other

Terminal/Shell

Other

Additional Information

NOTE ON THE FORM FIELDS: this is a Claude Desktop / Cowork bug, not a Claude
Code CLI bug. This repo has no Cowork issue template and blank issues are
disabled, so the CLI template is the only available route. "Claude Code
Version" is the Claude Desktop app version. "Operating System" is set to Other
because this reproduces on BOTH macOS and Windows.

ENVIRONMENT

• Claude Desktop (macOS): 1.34493.1
• Claude Desktop (Windows): 1.34493.1 <- identical
• Date observed: 2026-08-21
• Project under test: long-lived, ~3 months of accumulated memory, large

Memory panel

• Control Project: brand-new, empty, never used

API-SURFACE EVIDENCE

From inside a Cloud Cowork session, project inspection returns:

{
"name": "...",
"description": "...",
"instructions": "...",
"docs": [],
"files": [],
"sync_sources": [],
"knowledge": { "knowledge_size": 0, "max_knowledge_size": 2000000 }
}

There is no memory field at all -- not an empty one, the key is absent. The
session-initialization context enumerates the Project's name, description,
instructions and doc count (explicitly reporting "Project docs (0)"), but never
mentions memory. This is what makes the failure unobservable from inside.

MECHANISM EVIDENCE

The macOS Local session reported reading a per-project local cache directory.
For the long-lived Project this cache held a metadata.json plus a populated
memory store. For the brand-new control Project the same cache held only
metadata.json, with the memory store empty.

That is consistent with what we measured: Local sessions execute on the user's
machine and can reach that cache; Cloud sessions execute in an Anthropic-hosted
container and cannot. #44098 independently notes that Cowork auto-memory
"writes to a hardcoded local VM path", which corroborates this.

So this looks like an architectural consequence of where the memory delivery
channel was built, rather than a deliberate cloud-side restriction.

THE DOCUMENTATION CONTRADICTS ITSELF

"Organize your tasks with projects in Claude Cowork" states verbatim:

"Memory is enabled for Cowork projects. This means Claude can remember
context from tasks you've run in a project and apply it to future tasks in
the same project."

"Memory is scoped to the project, so what Claude learns in one project
doesn't carry over to others."

"Projects are desktop-only and stored locally. There's no cloud sync for
project data at this time."

-- https://support.claude.com/en/articles/14116274-organize-your-tasks-with-projects-in-claude-cowork

"Use Claude Cowork on web, desktop, and mobile" states verbatim:

"Projects are available on every surface. From a project you can start a chat
or a Cowork session, and Claude uses the project's knowledge as context."

"Projects tied to a local folder support Cowork sessions on desktop only."

-- https://support.claude.com/en/articles/15520349-use-claude-cowork-on-web-desktop-and-mobile

Three problems, measured against actual behaviour:

1. They disagree with each other. One says desktop-only with no cloud sync; the

other says available on every surface and used as context.

1. Neither matches reality. Project data DOES reach cloud sessions --

instructions arrive intact -- so "no cloud sync for project data" is not
accurate. But memory does NOT arrive, so "available on every surface" is not
accurate either. The real behaviour is partial delivery, which neither
article describes.

1. The one unqualified promise is the one that breaks. "Claude can remember

context from tasks you've run in a project and apply it to future tasks in
the same project" is stated without condition. In a Cloud session it does not
hold, and nothing in the product says so.

IMPACT

1. Silent degradation -- the main point. The model cannot observe the gap, so

it cannot warn the user or compensate. The user experiences "the answer was
worse this time" with no diagnosable cause. Every other missing input in
Cowork produces an error; this one produces silence.

1. The UI reinforces the wrong belief. The Memory panel renders identically

regardless of which environment a task will run in, and shows a full memory
store. Nothing at task-creation time indicates that choosing Cloud discards
it.

1. Cross-machine inconsistency. Same Project, same account, materially

different answer quality depending on an environment toggle that gives no
indication it affects context.

1. Compounds with a companion issue I am filing separately (Windows Local

cannot attach any Project). On Windows, Local cannot attach a Project at all
and Cloud gets no memory -- so no configuration on Windows delivers full
Project context. macOS + Local is the only one in the entire matrix that
does. That companion bug is also why the Windows + Local cell above is
untestable rather than merely untested.

REQUESTS, in priority order

1. Make it visible. At minimum, surface to both the user and the session that

memory is unavailable in this environment. A session that knows memory is
missing can compensate by reading source files; a session that cannot see
the gap cannot.

1. Reconcile the two help articles, and state plainly which parts of a Project

reach a cloud session and which do not.

1. If cloud-side memory delivery is planned, treat this as a parity gap and

prioritise accordingly.

RELATED (checked, all distinct)

• #37713 -- Cowork Dispatch sessions fully isolated from Projects; lists "empty

memory directory" among the losses. CLOSED AS NOT PLANNED. Prior art that
this pattern predates cloud sessions and has not been addressed. Scoped to
Dispatch, with no local-vs-cloud A/B, no cache mechanism, and no note that
the memory field is absent from the API surface.

• #44098 -- [FEATURE] Expose configurable memory and CLAUDE.md paths in Cowork.

Closed as not planned. Documents the hardcoded local VM memory path.

• #76143 -- Cowork's silent switch to remote-by-default sessions. Same class of

complaint (remote-by-default silently changes session capabilities); tracks
folder access, never mentions memory.

• #86647 -- Cowork session reports zero connected folders while the project UI

shows one connected. Precedent for "the UI shows a capability the session does
not have, with no warning."

• #55842, #30675, #25833 -- feature requests about unified/shared context across

surfaces. This report is NOT one of those: it is about a documented promise
silently failing in one execution mode, not a request to broaden memory's
scope.