[BUG] Cowork: expose execution mode (Local/Remote) as a visible per-project setting, and document what leaves the machine

FOLLOW-UP COMMENT — test result, 2026-09-08

Follow-up with a test result, since the one candidate control turned out not to be one.

Setup: Settings → Cowork → "Only on this computer" toggled on.

1. Created a new project. Card shows no Local badge.
2. Ran a prompt in it, so a real session existed. Card still shows no Local badge.
3. My pre-existing project continues to show Local, unchanged by the toggle in either direction.

So "Only on this computer" is not the local/remote execution control, and there is no control anywhere in Cowork that sets it. The Local badge appears to be a property of when a project was created, not something a user can choose or change.

This also means the badge can't be read as a statement about the current session: the project that carries it had a session running in a cloud container while the badge was displayed.

Net: a user who wants local execution has no path to it, and no reliable way to tell which mode they're in. That's the whole of the request in the original report.

Follow-up: I tested this behaviorally, and it contradicts part of my original report

In the original report I noted that the deterministic check — quit or sleep the machine and see whether execution stops — had not been run, and that I was reporting a session's self-report rather than asserting a mechanism. I've now run it. The result corrects one of my claims and sharpens the rest.

Correction

Steps to reproduce, item 4 stated that a session in a Local-badged project reported running in a cloud container. That was the session's own account of itself. Behavioral testing contradicts it: in that project, code execution is local. The sandbox suspends when the machine sleeps, which a remote container would not do.

I'm retracting that item. The badge described execution location accurately in the project I tested.

Method

Reproducible in about ten lines. Log wall-clock and the monotonic clock together, force a sleep mid-run, then compare how much monotonic time actually elapsed.

In a Cowork session:

L=/tmp/exectest.log; rm -f $L
echo "START epoch=$(date +%s) uptime=$(cut -d' ' -f1 /proc/uptime)" >> $L
for i in $(seq 1 45); do echo "$i epoch=$(date +%s) uptime=$(cut -d' ' -f1 /proc/uptime)" >> $L; sleep 2; done
echo "END epoch=$(date +%s) uptime=$(cut -d' ' -f1 /proc/uptime)" >> $L

In Terminal, immediately after starting it:

( sleep 15; pmset sleepnow ) &

Wake the machine after ~2 minutes and read the log. Expect the tool call to hit its timeout if execution is local — the suspension pushes total wall time past the limit. The log on disk is the evidence, not the tool call's return value.

The discriminator: compare wall-clock elapsed against /proc/uptime accrued.

• Monotonic clock stops while wall clock advances → the VM was suspended → local execution.
• Both advance together through the sleep → remote execution.

Cross-check the deficit against pmset -g log | grep -E "Entering Sleep|Wake from".

Results

Two projects, same machine, same evening. macOS 26.6.2, Apple Silicon, Claude for Mac 1.46388.4.

| Run | Project state | pmset sleep | Wall-clock jump in loop | Missing /proc/uptime | Verdict |
|---|---|---|---|---|---|
| A | conversation-level "Only on this computer" ON | (outside the tail -4 window I captured) | 73 s | 70.9 s | local |
| B | intermediate run | 38 s | 38.6 s | ~35 s | local |
| C | project carrying the Local badge | 91 s | 91 s | 88.4 s | local |

Run C in detail — entries 7 and 8, straddling the sleep:

7 epoch=1788909914 uptime=24930.40
8 epoch=1788910005 uptime=24932.40

Wall clock advanced 91 s. The monotonic clock advanced 2.00 s — exactly one sleep 2. Every other interval in the run ticked at a clean 2.00–2.01 s on both clocks, so this is one discrete freeze, not a general slowdown. pmset independently logs a 91-second sleep in that window.

Three clocks agreeing on the same interval. The sandbox is a VM on the local machine and it suspends with the host.

Why the session's self-report was wrong, and why that's worth fixing

A local sandbox presents a cloud-shaped interior: Linux aarch64, /sessions/... paths, NVMe block devices, a coworkd cgroup, no network interface at all with egress through an allowlist proxy. Asked where it is running, a session reads those signals and answers "a cloud container" — confidently, and wrongly.

I made that inference myself before running the test, from the same evidence.

So there are two distinct problems, and only one of them is the badge:

1. The UI doesn't expose execution mode. (Original report, unchanged.)
2. The assistant will confidently misreport its own execution location, and users treat that answer as authoritative because it sounds like introspection rather than inference. There is no reliable way for a session to distinguish local from remote without running a suspend test.

The second one is arguably worse, because a wrong badge is at least checkable against documentation, whereas a wrong self-report arrives with the model's apparent authority behind it. My original report existed because of it.

Revised asks

1. Execution mode as a visible per-project setting — unchanged, and still the main request. There is still no user control; mode appears to be a property of when a project was created. The Code tab already solves this ("Environment: choose where Claude runs. Select Local for your machine, Remote for Anthropic-hosted cloud sessions").

2. Verify the badge against behavior rather than remove it. Softened from the original. In the project I tested the badge was accurate. One project on one evening isn't proof it's reliable everywhere — particularly across the migration to cloud-by-default — but I can no longer say it's false, and I'm not going to assert more than I measured.

3. Document what crosses the network in each mode. This is now the primary ask.

Local execution does not mean local data, and nothing in the product distinguishes them. Even with execution confirmed on-device:

• the model runs on Anthropic's servers regardless of mode;
• any file the assistant actually opens is transmitted for inference;
• connected folders are exposed to the sandbox as FUSE mounts, which suggests on-demand proxying rather than bulk upload — but that's an inference from mount output, not something the docs state.

A user asking "what leaves my machine" cannot answer it from the interface today, and the answer they'd guess from a Local badge is wrong in an important way. One paragraph in the help center resolves it.

4. There are three separate control surfaces using three vocabularies, and none says local, remote, cloud, or execution:

• the project card's Local badge;
• Settings → Cowork → "Only on this computer" ("Stops when the app closes or this computer sleeps") — which my earlier test showed does not set execution mode;
• a per-conversation crossed-cloud icon in the title bar, unlabeled, whose tooltip describes lifecycle rather than location.

Consistent naming across those three would prevent most of this.

Incidental finding

While diagnosing why a clamshell close wasn't sleeping the machine, pmset -g assertions showed:

pid 55501(Claude): 07:15:22 NoIdleSleepAssertion named: "Electron"

The app had held a no-idle-sleep assertion for over seven hours. It's user-toggleable and I've since turned it off. Worth noting only because it interacts with the "Stops when … this computer sleeps" wording: a machine held awake by the app won't reach the state that stops the session.

Modal Text

I don't have the modal text from the dialog box shown today announcing cloud execution. This abrupt modal message began the hours of my investigation.

Beyond usability: a persistent affirmative indicator that misstates where processing occurs is a disclosure problem, not only a UX one. Users make data-handling decisions -- including decisions they've represented to their own clients -- in reliance on that badge. Documentation elsewhere doesn't cure a prominent on-screen claim that contradicts it. Provide a reliable badge and consistent, coherent framework.