Silent Default Switch: A Concern for Teams, Researchers, and Practitioners Using Claude Cowork

What happened

On July 7, 2026, Anthropic began rolling out a fundamental architectural change to Claude Cowork: sessions now run remotely on Anthropic's servers by default, rather than locally on the user's machine. The rollout is gradual; different users hit it at different times over several weeks, with no in-app warning before it takes effect.

For many users, the first sign that anything changed was unexpected behavior mid-session: permission prompts appearing on tasks that previously ran without them, local integrations silently failing, or unfamiliar access patterns in workflows that had been stable for months.

Why this matters beyond individual users

For research teams and practitioners with provenance-sensitive workflows

Many serious Claude Cowork users, researchers, analysts, and operations teams have built workflows that depend on direct, local filesystem access. Byte-level verification, file provenance tracking, and audit trails are not edge cases; they are how rigorous work gets done. When the execution model changes beneath those workflows without warning, the integrity of the record comes into question. A write that previously happened directly on-device now travels through a remote broker. Whether the output is byte-identical is not a trivial question, and it is one users should be able to answer before the change happens, not after.

For teams handling sensitive or regulated data

Under local execution, file contents processed by Cowork stayed on the user's machine, except as model inputs. Under remote execution, those contents are transmitted to and processed on Anthropic's infrastructure within a session sandbox. For teams working with proprietary research, client data, legally sensitive material, or anything subject to data residency requirements, this is a material change in data handling–and it happened by default, not by choice.

For anyone relying on local integrations

Local MCP servers do not run in remote sessions. This is documented but not surfaced at the start of the session. A team that has invested in local tooling and integrations can find those capabilities silently absent with no error, no warning, and no obvious explanation.

For scheduled and long-running tasks

Background execution, tasks continuing when the device is offline, is the primary capability the new architecture enables. It is genuinely useful. But it also means credentials and session tokens remain active and operational without the user present. For sensitive workflows, that is an expanded attack surface that warrants explicit acknowledgment and user consent, not a default-on setting.

The core concern: silent default switches on infrastructure changes

The individual capabilities introduced in this update are defensible. Background execution, cross-device continuity, and mobile access are legitimate product improvements. The concern is not the features but the rollout pattern.

Switching the execution model of an agentic tool from local to remote, by default, without an explicit opt-in prompt, on a gradual rollout schedule that means different users hit the change at different times, creates a situation where:

• Workflows break or behave unexpectedly with no clear cause
• Users investigate their own files and configurations, looking for errors that don't exist
• Data handling assumptions change without user awareness or consent
• The gap between documented behavior and experienced behavior grows

This is not hypothetical. It happened. A workflow that had run cleanly for months required hours of investigation before the root cause, a platform-level default switch, was identified. The files were fine. The configuration was fine. The platform had changed underneath.

What it cost in practice

The following is a direct account from this practitioner's experience on July 17, 2026–the day the rollout reached this account.

The session opened normally in Claude Cowork on the desktop app, running a governed, provenance-tracked research workflow that had operated without incident for months. The first anomaly: a mid-session permission prompt requesting access to a folder that had been continuously available in prior sessions. Unexpected, but granted.

What followed was a multi-hour investigation. The working assumption–reasonable, given no platform notification–was that something had changed locally. A full local environment audit was initiated: filesystem structure, Claude Code settings cascade, permissions model, hooks, plugins, binaries, and CLI versioning. Each hypothesis was tested against evidence before being set aside. Three separate root causes were proposed and ruled out. Unrelated but genuine configuration issues were surfaced and addressed along the way, adding scope and time.

The actual cause, a platform-level default switch from local to remote execution, was not identified until the following morning, when the unified Projects view and an unexplained permission prompt in a new session finally pointed in the right direction. The resolution was a single toggle in Settings > Cowork.

The workflow itself was not broken. The files were fine. The configuration was fine. The investigation consumed several hours of practitioner time, introduced uncertainty into a record that depends on verified provenance, and produced findings (a security audit, a CLI update, and plugin audits) that were useful but were not the work that day was supposed to accomplish.

This is the cost of a silent default switch on a tool used for serious, governed work. It is not a complaint about the feature. It is an account of what happens when infrastructure changes arrive without notice to the people whose work depends on them.

A brief in-app notification, or even a session-start disclosure, would have reduced the investigation to a two-minute settings change.

What better looks like

1. Explicit opt-in for execution model changes.
   A change from local to remote execution is not a minor update. It should require affirmative user action, not a toggle that ships on by default.
2. In-app notification before the change takes effect.
   Not a banner after the fact–advance notice, specific enough that users can assess impact on their workflows before the rollout reaches them.
3. Session-start disclosure.
   When a session runs under a different execution model than previous sessions in the same project, say so. One line at session open is sufficient.
4. Capability gap surfacing.
   If a local MCP server or integration is unavailable in the current session due to the execution model, surface that explicitly rather than silently omitting the capability.
5. Data handling transparency.
   When the execution model changes in ways that affect where data is processed, that change should be communicated with the same clarity as a terms of service update, because for many users, it effectively is one.

Who should read this

Anyone using Claude Cowork for work that involves: proprietary or sensitive data; file provenance and audit trails; local integrations or MCP servers; regulated industries; or any workflow where the assumption of local execution was load-bearing.

If you built your workflow before July 2026 and haven't checked your Cowork settings recently, check now: Settings > Cowork > "Run new tasks in the cloud." If it's on and you didn't turn it on, your sessions have been running remotely.

This brief reflects the experience and perspective of an independent practitioner. It is intended as constructive feedback to Anthropic and as a heads-up to the broader community of serious Cowork users.