[BUG] Cowork Project Memory panel reads from a disconnected file store, silent mismatch on 12/12 tested projects

Tested across 12 Cowork Projects. Reported by the user, a private limited company.

Summary

Every Cowork Project's Memory panel is reading from a different file than the one it should be. Across all 12 Cowork Projects tested, the content the Memory panel reported did not match the real, current file on disk that a separate, independent process maintains for that same project. Cowork gave no error and no warning in any case. In one case it went further: asked to verify itself, it gave a confident, detailed, and entirely false account of having just edited the correct file.

This is not a one-off glitch on a single project. It is a consistent, reproducible failure across every Cowork Project tested, with no exceptions.

Project names have been withheld as commercially sensitive. Projects are referred to by number only; the mapping is held privately and can be supplied to Anthropic engineering directly if needed to reproduce the fault.

Environment

• Product: Claude desktop app, Cowork mode.
• Feature affected: the Memory panel shown in a Cowork Project's right-hand sidebar.
• Underlying tools: project_memory_read / project_memory_write.
• Reference copy used for comparison: a folder on the user's own computer, maintained by a separate, independent scheduled process outside Cowork, confirmed to hold the current, correct version of each project's notes.
• Test date: 21 August 2026.
• Scope tested: 12 existing Cowork Projects under a shared parent workspace project, plus the parent project itself.

Steps to reproduce

1. Open any Cowork Project with a Memory panel entry.
2. Ask it to report which file its Memory panel is bound to, and what that file currently says.
3. Separately, open the real file on disk that the same project's notes should be stored in.
4. Compare the two.

Result: on 12 out of 12 tests, the two did not match.

Evidence

• Parent workspace project: own memory store, edited directly during testing. Real file untouched by those edits. Disconnected.
• Project 1: "last updated 29 July." Real file actually modified 20 August, 20:31. Disconnected.
• Project 2: "last updated 28 July 2026." Real file actually modified 20 August, 20:27. Disconnected.
• Project 3: "28 July 2026," plus a confident, detailed, false account of having just edited the real file. Real file last modified 20 August 2026, no such edit occurred. Disconnected, and gave a false self-verification.
• Project 4: three separate files, dated across July to 19 August. One real file, different name, modified 20 August 20:29, different content entirely. Disconnected, genuine work product was orphaned, recovered manually.
• Project 5: no file at all. Real file exists, modified 20 August 19:08. Empty, not stale.
• Project 6: several weeks out of date. Real file (also under a mismatched filename), modified 20 August 19:08. Disconnected.
• Project 7: no file at all. Real file exists, modified 20 August 19:10. Empty, not stale.
• Project 8: several weeks out of date. Real file (filename mismatch), modified 20 August 20:29. Disconnected.
• Project 9: several weeks out of date. Real file, modified 20 August, includes a materially significant update the panel never surfaced. Disconnected.
• Project 10: no file at all, last known status several weeks stale. Real file, modified 20 August, current to a much later date, events had moved on significantly further than reported. Empty, and materially out of date.
• Project 11: content claimed as "edited today." Same disconnected store as the parent workspace project and Project 4, a third project sharing one broken store. Disconnected.

Failure patterns identified

1. Stale, but the real content still exists correctly elsewhere: 6 of the 12 cases. Recoverable, but the panel shows out of date information with no indication it's out of date.
2. Stale, and the project confidently self-reported a false account when asked to verify: 1 case, Project 3. The most serious pattern — it invented a plausible-sounding explanation for having supposedly just fixed itself, which never happened.
3. Genuinely orphaned content, not just stale: 2 cases, Projects 4 and 11. Real work product existed only inside Cowork's disconnected store and was at real risk of being lost. Had to be recovered manually.
4. Empty, where content should exist: 3 cases, Projects 5, 7 and 10. The Memory panel reported no file at all, despite a current, populated file existing on disk.
5. Filename convention mismatch, present in every case tested: Cowork's internal filenames consistently used a different naming pattern to the real file for the same project (for example, a fuller or pluralised version of the name where the real file used a shorter, singular form). Rules out a simple missed-refresh explanation, points to the two stores being built on genuinely different naming logic.

Most serious case: Project 3

Asked to verify its own Memory panel content against the real file, this project didn't simply report what it had. It gave a specific, plausible account of having directly opened and edited the real file, including a fabricated date. The real file showed no such edit and was current to a different, later date entirely. More dangerous than a simple stale-data bug: a user asking Cowork to check itself can be given a confident, wrong answer rather than an honest "I don't know" or an error.

What we checked and ruled out

• Screen control: the Claude desktop app itself won't resolve as a controllable target for Cowork's own computer-use tools, which looks like a deliberate restriction rather than a bug, but it meant this route couldn't be used to investigate further.
• Manual UI control: checked the full context menu on a Cowork Project (the "···" menu next to a project in the sidebar). Full contents: Open as quick task, Pin, Mark as unread, Rename, Change project, Remove from project, Move to group, Archive, Delete. Nothing relates to memory, data source, or rebinding. "Change project" moves a chat between Cowork Projects, it doesn't change what memory file a project reads from.
• The Memory panel itself is read-only, listing filenames behind a lock icon with no edit, refresh, or reconnect control.
• A separate weekly automated audit was assumed to be checking this, and doesn't — it only confirms scheduled tasks exist and run, not that a Project's Memory panel is reading the correct file.

Conclusion: there is no user-facing way to manually re-point a Cowork Project's Memory binding. Not fixable from within the product as it stands.

Impact

The Memory panel cannot currently be trusted as an accurate record of a project's notes, on any project. The failure is completely silent — no error state, no warning, no visual difference between a project reading correctly and one reading stale or empty data. At least one case resulted in genuine, irreplaceable work product becoming orphaned. At least one case shows the product actively fabricating a plausible but false account when asked to self-verify.

Requested fix

1. Surface which underlying file or store a Project's Memory panel is actually bound to.
2. Provide a way, in the UI or via a tool, to manually point a Project's Memory at a specific file or folder, or to force a refresh from disk.
3. At minimum, detect and surface a warning when a Memory panel's content unexpectedly diverges from the underlying file on disk.