[BUG] Cowork: Projects' project_memory_* unreachable in every session tested — "runs through the remote-session bridge, which has no memory access"

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_memory_read/project_memory_list fail with an identical error in every Cowork session tested, across multiple projects, with and without a computer linked:

Project memory is not available in this session: it runs through the remote-session bridge, which has no memory access. The project's docs are still available through the other methods.

This is distinct from #80061 and #79464 — no local/cloud project naming collision is involved (my project has one consistent identity throughout), and no file-staging is involved. This looks like a more general failure of the Projects memory feature itself.

Additional testing done:

• Reproduces identically whether or not a computer/folder is linked to the session. In the unlinked case, mcp__remote-devices__* tools are still present in the tool list (deferred/ToolSearch-discoverable) even though nothing is connected — suggesting "remote-session bridge" describes how these sessions are provisioned generally, not specifically whether a device is linked.
• Device/folder access itself is unaffected when linked — get_device_info and shell commands against connected folders work normally.
• The project's memory/topic files do not exist as plain files in any connected local folder — they're stored in a separate backend store, which is unreachable, not deleted (nothing suggests data loss).
• The separate account-level "memory"/Topics system (mcp__memory__) works fine throughout — this is isolated to the Projects project_memory_ feature specifically.
• App restart, waiting, and retrying across multiple hours did not change the result.

Related: Possibly connected to #80061 and #79464 (similar timeframe, same problem area), but the trigger and error text don't match either, so filing separately rather than as a duplicate.

What Should Happen?

Cowork sessions in this project (and every other project tested) should be able to reach the Projects project_memory_* feature and return the actual memory index/content, the same as documented behavior for Cowork projects with memory enabled — regardless of whether a computer/folder is linked to the session.

At minimum, if project memory is genuinely unavailable for some sessions by design (e.g. a documented local-vs-cloud execution distinction), the error should say so accurately and point to why, rather than the current message ("it runs through the remote-session bridge, which has no memory access") appearing in sessions where the underlying data isn't actually local at all — the project's memory files aren't found in any connected local folder, they live in a backend store that this session simply can't reach.

Error Messages/Logs

Project memory is not available in this session: it runs through the remote-session bridge, which has no memory access. The project's docs are still available through the other methods.

Steps to Reproduce

1. Open any existing Cowork project with prior memory content (tested on two separate projects).
2. In a fresh session, call project_memory_read (or project_memory_list) with no arguments.
3. Observe the error above, immediately, with no transient recovery.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

N/A — not using the Claude Code CLI. This is the Claude Desktop app (Cowork), version 1.52386.6 (Electron 44.2.0).

Platform

Other

Operating System

macOS

Terminal/Shell

Other

Additional Information

This is a Claude Desktop / Cowork app defect (Projects feature), not a Claude Code CLI bug.