[BUG] Cowork silently moved a long-running local agent to the cloud, and cloud mode breaks its workflow

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?

A Claude Code update flipped Cowork's "Run new tasks in the cloud" toggle ON by default. My next Cowork session — which had always run locally on my Mac — silently started as a remote/cloud session (CLAUDE_CODE_ENTRYPOINT=remote_cowork, CLAUDE_CODE_REMOTE_ENVIRONMENT_TYPE=cloud_default, running as root@vm in /home/claude). I run a long-lived local agent whose state lives in a local memory folder and whose loop needs in-place file edits + local browser rendering. Forced cloud execution broke this, with three concrete failures:

1. A memory file that IS in the directory listing is unreadable. Listing the project-memory directory returns work-log.md, but reading it (project_memory_read, file="work-log.md") consistently returns: Memory file "work-log.md" does not exist. Smaller files in the same directory (MEMORY.md ~24KB, others) read fine the same session. work-log.md is the largest file (an append-only log). This looks like a per-file size cap in the memory-read path surfacing as a false "does not exist" instead of a size-limit/truncation result.

1. Device-bridge flicker: intermittent The device this session is bound to is not connected to the bridge on memory/file reads, which succeed on retry seconds later, with the desktop app open the whole time.

1. The execution-location default changed with no opt-in and no notice, silently moving an established local workflow to the cloud (behavior regression).

What Should Happen?

1. project_memory_read on a file that appears in the directory listing should return its content (or a truncated read), or an error naming the real cause (e.g. size limit) — never a false "does not exist".
2. The device bridge should stay connected while the desktop app is open, without intermittent "not connected" drops.
3. A Claude Code update should not silently change where existing sessions run (local -> cloud). Cloud execution should be opt-in for existing local users, or the prior local default preserved.

Error Messages/Logs

Steps to Reproduce

1. Have a Cowork workflow that runs locally, with a project-memory folder that contains a large file (an append-only log bigger than the memory-read size cap).
2. Update Claude Code; observe "Run new tasks in the cloud" is now ON by default.
3. Start a new Cowork session -> it starts as remote/cloud (CLAUDE_CODE_ENTRYPOINT=remote_cowork).
4. List the project-memory directory -> the large file is present in the listing.
5. Read that same file via project_memory_read -> returns Memory file "<name>" does not exist.
6. During the session, observe intermittent ... not connected to the bridge errors that succeed on retry.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.42

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

This is the Claude Desktop app (Cowork), NOT the Claude Code CLI in a terminal — the "Terminal/Shell" field doesn't really apply here. The session runs in Cowork's remote/cloud mode (CLAUDE_CODE_ENTRYPOINT=remote_cowork), reaching my Mac through the device bridge.

Workaround that restores the working local behavior: Settings -> turn OFF "Run new tasks in the cloud", then start a new session (the toggle only affects new tasks).

Of the three failures, the memory-read one is the most clearly reproducible: a file that IS present in the project-memory directory listing returns does not exist on read — likely a per-file size cap surfaced as the wrong error.

Screenshots attached: the "Run new tasks in the cloud" toggle, the Context panels (Folders vs Memory), and the errors.

<img width="1790" height="504" alt="Image" src="https://github.com/user-attachments/assets/9a76a2ab-5170-4451-8e64-0ab3fda17dba" />