[BUG] Cowork: sessions-api/sessions-bridge emit zero log output — device bridge never initializes (Windows, 1.40609.0.0)

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?

Cowork sessions cannot reach a connected local folder. Every remote-devices tool call
(device_bash, device_list_dir, get_device_info) fails with:

"The device this session is bound to is not connected to the bridge."

Reproduced 6 times over 11 minutes with no auto-recovery, despite the error text
promising recovery "within a few seconds."

THE DISTINGUISHING SYMPTOM (not reported in any existing issue): the bridge subsystem
emits ZERO log lines. Every marker from the healthy startup sequence appears 0 times in
the desktop logs — sessions-api, sessions-bridge, Registered environment, Reconnecting
session, Poll received work, Handling session work, Connecting transport.

Logging itself is healthy: main.log keeps writing for a further 30 minutes while I retry.
This is not a connection that drops. It is a subsystem that never starts.

REGRESSION: worked for months, broke after a Claude Desktop update.

BLOCKING, NO WORKAROUND: execution mode is not user-selectable, so on Windows reaching a
connected folder requires the bridge — there is no fallback. The workaround recommended
in #76054 (use pre-update sessions) does not apply: a project created MONTHS before the
update fails identically. The failure is device-scoped, not session-scoped.

HOST SYSTEMATICALLY ELIMINATED — all healthy:
VirtualMachinePlatform ....... Enabled (documented requirement satisfied)
Microsoft-Hyper-V-All ........ Enabled
CoworkVMService .............. Running / Automatic
Claude Desktop ............... MSIX 1.40609.0.0, intact, 8 processes running
Windows build ................ 26100
remote-devices MCP server .... responsive (refresh succeeds, toolCount 5) while
every device call it exposes fails

RELATED BUT NOT DUPLICATES:
#77385 — same error string, but the bridge logs normally there (partial-bridge state).
#76054 — pre-update sessions keep working there; they do not here. Also 1.19367.0.0
vs 1.40609.0.0, many builds later.
#76095, #38783 — capability/provisioning defects in the same layer.

QUESTION: what gates sessions-bridge initialization? It produces no output at all here.

What Should Happen?

A Cowork session bound to a device with a connected folder should complete bridge attach
and expose working device tools, so file operations against the connected folder succeed.

Concretely, after "grantRemoteSessionFolders" and "Config file written", the session
should proceed through Registered environment → Reconnecting session → Poll received
work → Handling session work → Connecting transport, as it does on working hosts.

Failing that, the failure should be visible before a tool call fails mid-task, and the
documented auto-recovery should actually occur.

Error Messages/Logs

Tool error (identical on every device call, 6 occurrences over 11 minutes):

  The device this session is bound to is not connected to the bridge.

MCP server responsive at the same moment every device call fails:

  [{"server":"remote-devices","status":"refreshed","toolCount":5,"added":[],"removed":[]}]

Session lifecycle truncation (%LOCALAPPDATA%\Claude\logs\main.log):

  2026-09-01 10:28:27 [info] Config file written
  2026-09-01 10:29:13 [info] LocalAgentModeSessions.grantRemoteSessionFolders: cse_REDACTED [1]
  2026-09-01 10:29:13 [info] Config file written
  -- nothing further for this session; main.log continues to 10:58:05 --

Marker counts across all collected logs:

  sessions-api ............. 0
  sessions-bridge .......... 0
  Registered environment ... 0
  Reconnecting session ..... 0
  Poll received work ....... 0
  Handling session work .... 0
  Connecting transport ..... 0

Separate file-access failure the previous day, different code path:

  2026-08-31 13:52:40 [warn] LocalFileAccessError: [INVALID_PATH]
    Failed to resolve path: C:\Users\jdoe\Desktop\PROJECT\SUBFOLDER\FILENAME.md

Note: cowork_vm_node.log was modified at 10:29:13 — the exact second of failure — but
contains nothing matching a deliberately broad filter.

Steps to Reproduce

Environment: Windows 11 (build 26100), Claude Desktop MSIX 1.40609.0.0, Cowork with a
connected local folder. Host prerequisites verified: VirtualMachinePlatform Enabled,
CoworkVMService Running/Automatic.

1. Connect a local folder to a Cowork project (Add folder).
2. Confirm the desktop app is running and online on that machine.
3. Start a Cowork task bound to that computer (cloud-executed session — the default;

execution mode is not user-selectable).

1. Ask Claude to list or read any file in the connected folder, i.e. trigger any

remote-devices call (device_list_dir, device_bash, get_device_info).

1. OBSERVED: every call fails with

"The device this session is bound to is not connected to the bridge."
Retried 6 times over 11 minutes — no auto-recovery.

1. Repeat with a Cowork project created BEFORE the update → fails identically.

(This is what rules out the #76054 workaround.)

1. Inspect the desktop logs:

%LOCALAPPDATA%\Claude\logs\main.log
The session stops after "Config file written" and never appears again.

1. Confirm the bridge subsystem produced no output at all:

Select-String -Path "$env:LOCALAPPDATA\Claude\logs\*.log" `
-Pattern 'sessions-api|sessions-bridge|Connecting transport|Registered environment'

RESULT: zero matches — while main.log continues writing normally for 30+ minutes.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Unknown — last worked week of 2026-08-24; MSIX auto-updated and the prior version was not recorded.

Claude Code Version

Claude Desktop 1.40609.0.0 (MSIX) — not Claude Code CLI

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

NOTE ON FORM FIT: this form is oriented to the Claude Code CLI. This is a Claude Desktop /
Cowork bridge defect, so "Claude Code Version" and "Terminal/Shell" don't map cleanly.
Versions given above are for Claude Desktop.

SECOND DEFECT — capabilities advertised but never provisioned:
The session context stated "Computer use is available on device <hostname> via the
computer_* tools", and referenced device_request_folder_access and
device_request_delete_permission. None of these tools existed in the session; a targeted
lookup returned no matches. The actual surface was 5 tools (device_bash,
device_commit_files, device_list_dir, device_stage_files, get_device_info).

Even if that is a downstream symptom of the device being offline, the prompt asserted
computer-use availability on a NAMED device that was unreachable — i.e. session context
was built from a cached device record rather than verified live presence.

UNCONFIRMED LEAD — MSIX path virtualization:
The app logs a session-store path under AppData\Roaming\Claude\ and reports
"[Spaces.listFolderContents] failed to resolve path" against it, while the data lives at
the virtualized ...\Packages\Claude_<pubhash>\LocalCache\Roaming\Claude\. The string
"LocalCache" appears 0 times in the logs, two separate log trees exist on disk (one
inside the package container, one outside), and the on-disk session store holds only two
records, both dated 2026-05-05, despite continuous use since.
Flagged as a lead, NOT a claim — MSIX redirects AppData\Roaming transparently, so this
may be benign.

ENVIRONMENT CONTEXT:
Government-managed enterprise endpoint (MDM). Local admin held, but MDM policy outranks
it. Triage may want to consider AppLocker restrictions on packaged apps and the
documented MDM/auto-updater version conflict.

WHAT WAS RULED OUT (so this isn't triaged as user misconfiguration):
VirtualMachinePlatform Enabled · Microsoft-Hyper-V-All Enabled · CoworkVMService
Running/Automatic · MSIX install intact, 8 processes running · Windows build 26100 ·
remote-devices MCP server responsive (refresh succeeds, toolCount 5) while every device
call it exposes fails · app restarted (fresh start logged at 10:26:34, bridge still
emitted nothing afterward).

Full sanitized write-up with log excerpts and the elimination table available on request.
Raw desktop logs not attached here (managed endpoint) — happy to provide them privately
via support.