[BUG] Cowork Windows: Local environment cannot attach ANY Project — "Projects can't be included in sessions that run on this computer" (macOS unaffected, identical app version)

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?

On Windows, creating a Cowork Task inside ANY Project with the "Local"
environment selected fails immediately. No task is created. The same app
version on macOS works correctly.

The failure is specific to the intersection of three conditions:
Windows + Local environment + a Project attached. Remove any one of the three
and it works:

• Windows + Local + NO project -> works
• Windows + Cloud + project -> works
• macOS + Local + project -> works
• Windows + Local + project -> FAILS, 100% of the time

It reproduces with a brand-new, completely empty Project (0 docs, 0 files,
0 knowledge bytes), so it is not related to Project content. It also fails
whether or not a folder has been authorized, and regardless of which folder.

What Should Happen?

The Project should attach and the session should run locally, exactly as it
does on macOS with the identical app version.

Error Messages/Logs

Projects can't be included in sessions that run on this computer. Switch the session back to cloud, or remove the folder or permission setting that keeps it local.

Steps to Reproduce

1. On Windows, open Claude Desktop 1.34493.1.
2. Create a brand-new Project. Leave it completely empty — no folder,

no documents, no knowledge files, no custom instructions.

1. Inside that Project, create a new Cowork Task.
2. Select the "Local" environment.
3. The task fails to start. The error above is shown.

Reproduces 100% of the time.

Control tests that isolate the cause — all four were run:

A. Same Windows machine, same Project, select "Cloud" instead of "Local"
-> works
B. Same Windows machine, "Local" environment, but NOT inside any Project
-> works
C. Same Windows machine, "Local" + Project, with a folder authorized
(several different folders tried)
-> still fails
D. macOS, Claude Desktop 1.34493.1 (identical version), "Local" + Project,
both a long-lived Project and a brand-new empty one
-> both work

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

1.34493.1

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

NOTE ON THE FORM FIELDS: this is a Claude Desktop / Cowork bug, not a Claude
Code CLI bug. This repo has no Cowork issue template and blank issues are
disabled, so the CLI template is the only available route. "Claude Code
Version" above is the Claude Desktop app version (1.34493.1). "Terminal/Shell"
is set to Other because no terminal is involved.

ENVIRONMENT

• Claude Desktop (Windows): 1.34493.1
• Claude Desktop (macOS): 1.34493.1 <- identical
• Electron / Node (Windows): 42.9.2 / 24.18.1
• Platform / arch: win32 / x64
• Date observed: 2026-08-21

CONFIGURATION MATRIX (every cell measured, not inferred)

| Platform | Environment | Project attached | Result |
|----------|-------------|-----------------------|----------|
| macOS | Local | Yes (existing) | Works |
| macOS | Local | Yes (brand-new empty) | Works |
| macOS | Cloud | Yes | Works |
| Windows | Cloud | Yes | Works |
| Windows | Local | No | Works |
| Windows | Local | Yes (any Project) | FAILS |

VARIABLES RULED OUT

| Variable | Test | Result |
|-------------------------|-----------------------------------------------|---------------------|
| Project content | Brand-new empty Project (0 docs/files/bytes) | Reproduces |
| Folder authorization | No folder; and several folders granted | Fails in every case |
| Local MCP configuration | Present / absent | No effect |
| App version | macOS on identical 1.34493.1 | Works |
| Local mode itself | Windows + Local, no Project | Works |
| Cloud mode | Windows + Cloud, with Project | Works |
| Project age | Long-lived Project and freshly created one | Both fail |

THE ERROR MESSAGE IS NOT ACTIONABLE

The message offers two remedies. The first (switch to cloud) works. The second
-- "remove the folder or permission setting that keeps it local" -- cannot be
followed: there is no folder or permission to remove. What keeps the session
local is the user's own explicit selection of the Local environment in the
task-creation UI. A user following this advice will search for a setting that
does not exist.

If the restriction is intentional, the message should say so plainly, e.g.
"Projects are not currently supported in Local sessions on Windows." If it is
not intentional, the guard condition is wrong.

THIS ALSO CONTRADICTS THE DOCUMENTATION

The Cowork projects help article states verbatim:

"Projects are desktop-only and stored locally. There's no cloud sync for
project data at this time."

-- https://support.claude.com/en/articles/14116274-organize-your-tasks-with-projects-in-claude-cowork

So the documented model is that Projects live on the desktop, locally. Yet
desktop + local is precisely the configuration Windows blocks, and the error
directs the user to the cloud -- the environment that same article says project
data does not sync to.

POSSIBLE MECHANISM (speculative -- inference from symptoms, not from source)

The Windows client ships as an MSIX/Store package (Claude_pzs8sxrjxfjjc, under
WindowsApps); macOS ships as a plain .app. Windows local execution runs in a VM
with Plan9/VirtioFS mounts. If Project context injection requires staging a
file into that VM, it may be hitting the packaged-sandbox VFS limitation
already reported in #48289, which produces similar symptoms from a different
code path. Offered only as a starting point for triage.

IMPACT

Windows users cannot combine Local execution with Projects at all. The
workaround (switch to Cloud) is not cost-free: files must be copied into a
remote container rather than accessed directly, locally-installed MCP servers
are proxied and may break, scripts cannot run against the local machine, and
files leave the user's computer. For Projects holding sensitive material that
is not a neutral tradeoff.

It also compounds with a companion issue I am filing separately: Cloud sessions
do not receive Project memory. Because Windows Local cannot attach a Project at
all, and Windows Cloud gets no memory, there is no configuration on Windows
that delivers full Project context. macOS + Local is the only one that does.

RELATED (checked, all distinct)

• #76143 -- Cowork's silent switch to remote-by-default sessions. Same

Local-vs-cloud x Project axis, but macOS, silent, no error. The isolation
matrix above is what that issue lacks.

• #76187 -- Cowork Windows: project context folders never mount in new

sessions. Same platform + Projects, but silent and folder-specific; this bug
reproduces with no folder at all.

• #73852 -- adding a folder to an ongoing session fails with a policy-flavoured

refusal; possibly the same permission-check subsystem emitting our string.

• #26103 -- Cowork rejects project folders outside the user home directory

(non-C: drives). Adjacent Windows path/permission gating.

• #69663 -- Cowork local-agent-mode sessions missing from Recents (Windows);

confirms Windows local-agent mode is a distinct code path.

• #48289 -- Windows MSIX/WindowsApps VFS limitation; similar failure signature

from a different path.

I searched for the verbatim error string across GitHub and the open web before
filing. It does not appear anywhere. This looks like the first report.