[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
- On Windows, open Claude Desktop 1.34493.1.
- Create a brand-new Project. Leave it completely empty — no folder,
no documents, no knowledge files, no custom instructions.
- Inside that Project, create a new Cowork Task.
- Select the "Local" environment.
- 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.
3 Comments
Still reproduces on Claude Desktop 1.52386.6 (Windows 11 Enterprise 10.0.26200,
MSIX/Store package Claude_1.52386.6.0_x64__pzs8sxrjxfjjc under
C:\Program Files\WindowsApps).
The original report was filed against 1.34493.1. The guard condition has therefore
survived every build in between, unchanged, with the same non-actionable error string.
Two additional data points from my own environment that are not in the original report:
ACCOUNT, not to the device. Changing it on one machine changes it on every machine
signed in to the same account. So a user with two Windows machines cannot keep one
in Local mode and the other in Cloud as a workaround: the toggle is global, and the
choice of execution mode is forced to be identical everywhere.
Project context: Local cannot attach a Project at all, Cloud attaches it but drops
the memory. The matrix has no working cell on this platform.
IMPACT for me, concretely: I am migrating 15 Cowork projects from one work machine to
another. The migration is blocked outright. These are long-lived projects with months
of accumulated memory, used daily, and the cloud
workaround is not acceptable here because the underlying folders hold material that
should not leave the corporate machine.
Happy to run any diagnostic on request. I can test on both a Windows and a macOS box
on identical app versions, which is how the original isolation matrix was produced.
Still reproduces on 2.110.0. Retested today on a fresh session, and the
isolation from the original report holds unchanged.
VERSION CHAIN
1.34493.1 original report
1.52386.6 @Massimo76GE's reproduction
2.110.0 today (build dfb2ba)
This guard condition has now survived a major version transition. That is worth
flagging because the same transition demonstrably reworked other parts of
project context delivery -- project memory now reaches Cloud sessions, which it
did not when this was filed (see #88640). So this code path was adjacent to work
that shipped and still went untouched.
RETEST
same error string, character for character:
"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."
normally.
CORRECTION TO THE ORIGINAL REPORT'S IMPACT SECTION
The original report argued that "there is no configuration on Windows that
delivers full Project context", because Local could not attach a Project and
Cloud received no Project memory. The second half of that is no longer true on
2.110.x -- Cloud sessions now do receive the project's memory (verified by
content and file-count comparison against the desktop Memory panel; details in
#88640). So Cloud is now a genuinely usable workaround for this bug, and the
compounding harm I described has largely gone away.
I would rather correct that myself than have it stand as an overstated claim.
WHAT REMAINS
The bug itself is unchanged, and two things about it still matter:
macOS users can, on identical versions. That is a plain platform parity gap.
@Massimo76GE's case it costs everything: his blocker is that the material
must not leave a corporate machine, so "switch to Cloud" is not available to
him, and the memory fix does not help him at all. His migration of 15
projects is still blocked.
to remove -- what keeps the session local is the user's own explicit choice
of the Local environment. If the restriction is intentional on Windows, the
message should say that.
Environment for the retest: Windows 2.110.0 (dfb2ba, built 2026-09-15);
comparison machine macOS 2.110.1.
**Additional report: on Windows, Projects and local folder access are mutually exclusive in every combination — not only the Local+Project case originally reported**
Environment:
All of the following reproduce 100% for me:
New Cowork task inside a Project, with a local folder added in the
composer before sending. The task immediately shows the banner:
*"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."*
I never selected Local — adding the folder appears to silently force
the session to Local, which then trips the Project guard.
no Local/Cloud toggle anywhere in the composer or the task view.
"Only on this computer" or similar setting anywhere in Settings.
Creating the task in the Project as a plain cloud task (no folder)
works. But from inside the running task, the "+" only accepts single
file attachments, exactly like chat. There is no option to connect a
folder or link the computer to an already-running cloud task.
Net effect on Windows: Local+Project is blocked (as originally reported),
Cloud+Project+folder is blocked because adding a folder forces Local, and
folders cannot be connected post-creation. So a workflow where the Project
holds instructions/memory and a local folder holds the working files is
currently impossible on Windows, while the same setup works on macOS.