[FEATURE] Cowork: surface local vs. cloud execution mode in the composer, and say when local context isn't loaded

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

I can't tell which mode a Cowork session is running in, and the difference between the two modes is enormous for me.

My setup lives in local files: a global CLAUDE.md, user preference files, a persistent context library, and local skills. In local mode all of that loads and Claude works the way I've built it to work. In cloud mode, with no bridge to the desktop, none of it is reachable — which I understand is by design, not a malfunction. Cloud mode is doing exactly what it's built to do.

The problem is that nothing tells me which one I'm in. The only signal is a small monochrome monitor glyph in the top-right corner of the window — roughly 12px, unlabeled, in the least-observed region of the UI. No text, nothing near the composer where I'm actually looking.

And because the mode is invisible, its consequences arrive undiagnosable. When a cloud session can't load my local context, it doesn't say so. Claude simply behaves like it has never seen my configuration — ignoring rules it should have loaded, missing skills it should have triggered. The symptom (Claude acting like a stranger) is several steps removed from the cause (wrong execution mode), and nothing in the interface connects the two.

I ran four sessions in cloud mode today before I figured out what was happening. Each one I spent trying to diagnose why the assistant had forgotten everything about my work. Four sessions, one day, no signal available to debug against — until I happened to notice the icon.

For anyone whose Cowork setup depends on local files, cloud mode without a desktop bridge isn't a degraded version of local mode. It's a different product. I need to know which one I'm talking to.

Proposed Solution

Three changes, in order of value to me:

1. Put the mode in the composer as a text chip.

Replace (or supplement) the corner glyph with a labeled chip sitting next to the prompt input, reading Local or Cloud. The composer is where my attention already is at the exact moment the mode matters — right before I send work. A word beats an icon; the current glyph doesn't read as stateful or as a control, and at ~12px in the top-right corner it's in the least-observed region of the window.

2. Announce the consequence, not just the state.

When a session starts in cloud mode and local context can't be loaded, say so in the session:

Running in cloud mode — local CLAUDE.md, preference files, and skills are not loaded.

This is the one that matters most. It converts a multi-session mystery into a single line of text I can act on immediately. Even with no UI change at all, this alone would have saved me four sessions. It's also the cheapest of the three to build.

3. Persist the mode per workspace, or confirm on change.

So the mode doesn't quietly flip between sessions without my noticing.

If only one of these is worth building, build #2.

Alternative Solutions

What I do now: check the corner icon manually before starting real work. This depends entirely on me remembering that the icon exists, which is exactly what failed four times in one day. A workaround that relies on the user remembering an invisible control isn't a workaround.

Also considered: opening every session by asking Claude whether it can see my local files. That works, but it burns a turn on every session to retrieve state the app already knows and could simply display.

Prior art: most tools that run in more than one execution context label it in the chrome rather than encoding it as an unlabeled glyph — remote/local indicators in VS Code (bottom-left, colored, with text), git branch indicators in most IDEs, environment banners (staging / production) in web consoles. The common pattern is a text label placed in the user's working sightline, and it exists because silent context switches are expensive.

Priority

High - Significant impact on productivity

Feature Category

Other

Use Case Example

A real scenario from today, walked through step by step:

1. I open the Claude desktop app and start a Cowork session. My machine has a global CLAUDE.md, preference files, a context library, and local skills configured.
2. The session opens in cloud mode. I don't notice — the only signal is the corner glyph, and I'm looking at the composer.
3. I ask for something governed by rules in CLAUDE.md. Claude answers, but ignores those rules entirely. No warning appears. Nothing indicates my configuration wasn't loaded.
4. I assume my instructions are wrong. I spend the session trying to fix rules that were never read in the first place.
5. Repeat, three more times.

With the proposed feature, step 2 becomes: I glance at the composer, see the Cloud chip next to the input, and either switch to local or proceed knowing my context isn't there.

Or, with proposal #2 alone, step 3 becomes: Claude opens with "Running in cloud mode — local CLAUDE.md, preference files, and skills are not loaded." I switch modes and lose thirty seconds instead of an afternoon.

The saving isn't just time. It's the difference between trusting the tool and suspecting my own configuration is broken — the second one is corrosive, because it sends me editing files that were working fine.

Additional Context

Surface: Cowork (research preview) in the Claude desktop app. Windows 11 Pro (10.0.26200), Claude Code 2.1.202 bundled with the desktop app. Filing here since Cowork reports are triaged in this repo.

Framing: I want to be clear that cloud mode not reaching my local files isn't a defect. It's the design, and it's reasonable. This request is only about legibility: the app knows which mode it's in and knows whether local context loaded, and it currently keeps both facts to itself. Surfacing state the system already has is a small change standing in front of a large and repeated cost.

Related but distinct: #75814 asks for a single session that is both chat-synced and locally executing — a capability request. This one assumes the two modes stay separate and asks only that the current mode, and its consequences, be visible.

Proposal #2 (announce when local context isn't loaded) is the cheapest item here and captures most of the value. If the UI work in #1 is more than it's worth, #2 alone would resolve this.