[BUG] Desktop Bridge Failure

[myerena]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

[BUG] Windows: sessions created after app update never receive device-bridge connection (old sessions reconnect fine)

Environment

• App: Claude Desktop 1.19367.0.0, MSIX package (Claude_1.19367.0.0_x64__pzs8sxrjxfjjc), installed from latest download on 2026-07-09
• OS: Windows 10 Home, 64-bit (x64)
• Environment ID: env_01M9RG... (truncated; stable since 2026-07-06, re-registered successfully on every app launch including after update — full IDs available on request)

Summary

After updating the desktop app, every newly created Cowork session fails to attach the desktop bridge (remote-devices MCP server absent in the session — no device file access, no computer use, no project memory). Sessions created before the update reconnect and work normally through the same app, same machine, same account. Reproduced across ~10 new sessions. Restarting the app, restarting the PC, and re-checking folder/connection settings do not help.

Evidence from logs (...\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\main.log)

Old session (created 2026-07-06) — works. On app launch today it is explicitly re-bound and dispatched:

2026-07-09 06:43:17 [sessions-api] Registered environment: env_01M9RG...
2026-07-09 06:43:17 [sessions-api] Reconnecting session cse_01NUiY... to environment env_01M9RG...
2026-07-09 06:43:19 [sessions-api] Poll received work: id=cse_01NUiY... type=session
2026-07-09 06:43:19 [sessions-api] Acknowledging work cse_01NUiY... for environment env_01M9RG...
2026-07-09 06:43:19 [sessions-bridge] Handling session work { sessionId: 'cse_01NUiY...', ... }
2026-07-09 06:43:19 [sessions-bridge] Connecting transport for session cse_01NUiY...

New session (created 2026-07-09, after update) — fails. Folder grant happens, then nothing — no poll work, no sessions-bridge handling, no transport:

2026-07-09 06:58:47 LocalAgentModeSessions.clearRemoteSessionFolderGrants: cse_01WzoA...
2026-07-09 06:58:49 LocalAgentModeSessions.grantRemoteSessionFolders: cse_01KXqA... [1]
2026-07-09 06:58:49 Config file written
2026-07-09 06:58:49 [oauth] using cached token for orgId=073ac...
2026-07-09 06:58:50 [VM] getVMStorageSubpath: vmStorageDir=C:\Users\...\claude-code-vm, ...
(no further entries for cse_01KXqA... — grep confirms the grant lines are the ONLY occurrences of this session ID in main.log)

Local VM is healthy (cowork_vm_node.log same morning):

06:43:26 [VM:steps] vm_boot completed (154ms)
06:43:26 [VM:steps] add_plan9_shares completed (3ms)
06:43:31 [VM] Network status: CONNECTED
06:43:34 [VM] API reachability: REACHABLE
06:43:34 [VM:start] Startup complete, total time: 8733ms

No errors or warnings related to devices/bridge/websocket in any log.

Impact

Inside affected sessions, the remote-devices MCP server is absent entirely (Server "remote-devices" not found. Available servers: Canva, Slack, claude-code-remote, visualize), while all other MCP servers attach normally. Connected-folder metadata still appears in the session context, but no device tools exist. Users are pinned to pre-update sessions for any local-file work.

Steps to reproduce

1. Windows 10 Home x64, Claude Desktop updated to 1.19367.0.0 (MSIX)
2. Create a new Cowork session with a connected folder
3. Ask Claude to list the folder / use any device tool → server absent
4. Open a session created before the update → device tools work

What was tried (no effect)

• Full app restart (from tray) and PC restart
• Verified CoworkVMService running
• Verified folder connection settings
• ~10 fresh sessions, all fail identically

What Should Happen?

new sessions should connect

Error Messages/Logs

Steps to Reproduce

[BUG] Windows: sessions created after app update never receive device-bridge connection (old sessions reconnect fine)

Environment

• App: Claude Desktop 1.19367.0.0, MSIX package (Claude_1.19367.0.0_x64__pzs8sxrjxfjjc), installed from latest download on 2026-07-09
• OS: Windows 10 Home, 64-bit (x64)
• Environment ID: env_01M9RG... (truncated; stable since 2026-07-06, re-registered successfully on every app launch including after update — full IDs available on request)

Summary

After updating the desktop app, every newly created Cowork session fails to attach the desktop bridge (remote-devices MCP server absent in the session — no device file access, no computer use, no project memory). Sessions created before the update reconnect and work normally through the same app, same machine, same account. Reproduced across ~10 new sessions. Restarting the app, restarting the PC, and re-checking folder/connection settings do not help.

Evidence from logs (...\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\main.log)

Old session (created 2026-07-06) — works. On app launch today it is explicitly re-bound and dispatched:

2026-07-09 06:43:17 [sessions-api] Registered environment: env_01M9RG...
2026-07-09 06:43:17 [sessions-api] Reconnecting session cse_01NUiY... to environment env_01M9RG...
2026-07-09 06:43:19 [sessions-api] Poll received work: id=cse_01NUiY... type=session
2026-07-09 06:43:19 [sessions-api] Acknowledging work cse_01NUiY... for environment env_01M9RG...
2026-07-09 06:43:19 [sessions-bridge] Handling session work { sessionId: 'cse_01NUiY...', ... }
2026-07-09 06:43:19 [sessions-bridge] Connecting transport for session cse_01NUiY...

New session (created 2026-07-09, after update) — fails. Folder grant happens, then nothing — no poll work, no sessions-bridge handling, no transport:

2026-07-09 06:58:47 LocalAgentModeSessions.clearRemoteSessionFolderGrants: cse_01WzoA...
2026-07-09 06:58:49 LocalAgentModeSessions.grantRemoteSessionFolders: cse_01KXqA... [1]
2026-07-09 06:58:49 Config file written
2026-07-09 06:58:49 [oauth] using cached token for orgId=073ac...
2026-07-09 06:58:50 [VM] getVMStorageSubpath: vmStorageDir=C:\Users\...\claude-code-vm, ...
(no further entries for cse_01KXqA... — grep confirms the grant lines are the ONLY occurrences of this session ID in main.log)

Local VM is healthy (cowork_vm_node.log same morning):

06:43:26 [VM:steps] vm_boot completed (154ms)
06:43:26 [VM:steps] add_plan9_shares completed (3ms)
06:43:31 [VM] Network status: CONNECTED
06:43:34 [VM] API reachability: REACHABLE
06:43:34 [VM:start] Startup complete, total time: 8733ms

No errors or warnings related to devices/bridge/websocket in any log.

Impact

Inside affected sessions, the remote-devices MCP server is absent entirely (Server "remote-devices" not found. Available servers: Canva, Slack, claude-code-remote, visualize), while all other MCP servers attach normally. Connected-folder metadata still appears in the session context, but no device tools exist. Users are pinned to pre-update sessions for any local-file work.

Steps to reproduce

1. Windows 10 Home x64, Claude Desktop updated to 1.19367.0.0 (MSIX)
2. Create a new Cowork session with a connected folder
3. Ask Claude to list the folder / use any device tool → server absent
4. Open a session created before the update → device tools work

What was tried (no effect)

• Full app restart (from tray) and PC restart
• Verified CoworkVMService running
• Verified folder connection settings
• ~10 fresh sessions, all fail identically

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

1.19367.0.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

No response

[Philosopherking214]

Reproducing this on macOS — same signature as OP's Windows report.

Environment: Claude Desktop 1.24012.0, Electron 42.7.0, Node 24.18.0, macOS arm64 (Mac14,15), Cowork cloud session.

New-session bridge attach fails while existing sessions keep working:

• New session created with a folder connected: session receives the folder registration and CLAUDE.md context snapshot, but the remote-devices server exposes only get_device_info, which returns "The device this session is bound to is not connected to the bridge." The device_* file tools never register.
• Concurrent older sessions on the same device had full file access throughout.
• Full app quit/reopen did NOT heal the broken session (consistent with OP's "restart has no effect").
• What DID heal it: re-adding the folder to the session ("Add folder"), which forced a fresh registration — tools appeared ~2–5 minutes later. This matches the grantRemoteSessionFolders-fires-but-no-session-work-dispatch signature in OP's logs: the grant event goes through, and forcing a new grant appears to re-trigger the missing attach.
• Recurring: has happened on multiple new sessions across days.

Possibly aggravating: this device has duplicate connector registrations (two filesystem MCP connectors named "filesystem"/"Filesystem", and two Chrome extension records for one machine) — flagging in case stale/duplicate device records contribute to binding against a record the app doesn't serve.

Cross-ref: after the re-grant healed the session, the bridge then dropped mid-session three separate times with no auto-recovery — that half of the behavior matches #77385.