[BUG] Cowork device bridge stopped connecting to trusted local folders — worked for 2 months, no local changes, unresolved 24+ hours

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?

[BUG] Cowork device bridge stopped connecting to trusted local folders — worked for 2 months, no local changes, unresolved 24+ hours

Summary

The Cowork device bridge on Windows abruptly stopped connecting to my trusted local folders approximately 24+ hours ago. Cloud Cowork sessions can no longer reach files on my desktop. This configuration worked reliably for roughly two months before failing with no changes on my end. All standard troubleshooting has been exhausted. Timing appears to coincide with Anthropic's Cowork remote announcement/rollout, which raises the possibility of a server-side regression rather than a local configuration issue.

Environment

• OS: Windows (user profile: C:\Users\talbd)
• App: Claude Desktop (latest as of 2026-07-09; auto-updated)
• Account: talbdoug@gmail.com (same account signed in on desktop app and web)
• Feature: Cowork device bridge / local trusted folder access
• Working history: Daily/regular use of this exact setup for ~2 months prior to failure

Trusted folder configuration (verified intact)

The following folders are confirmed present under Settings → Trusted Cowork folders (screenshot available):

• C:\Users\talbd\Documents\Cowork Book Business
• C:\Users\talbd\Documents\Cowork Book Business\Books\Magic Carpet Ride\Book 1 - The Sayre Deception\... (added additionally, pointing directly at the chapter files)
• Several other folders (Cowork, Cowork Test Folder, Claude\Projects\test)

Symptoms

1. New Cowork sessions (started from the desktop app, with the folder attached) cannot access the trusted folder. Claude reports it "can't reach your computer right now" / device tools fail to load.
2. Partial staging anomaly: In at least one session, only CLAUDE.md from the project folder was staged into the session workspace — the rest of the project folder never arrived. This suggests the bridge handshake begins and then fails/drops rather than never starting.
3. Behavior is inconsistent across sessions: earlier, one session (Chapter 4 work) connected fine while another (Chapter 7 work) could not — same folder, same account, same machine.
4. Claude sessions confirm from their side that no mcp__remote-devices__* tools are available at session start.

Related event (possibly relevant, now resolved)

During troubleshooting I force-quit the desktop app via Task Manager. On relaunch I received:

Failed to start Claude's workspace — VM service not running. The service failed to start. Restarting Claude or your computer sometimes resolves this. If it persists, you can reinstall the workspace or share your debug logs.

That error self-resolved after about a minute and has not returned. The VM/workspace now starts normally — but the bridge still does not connect. These appear to be two separate failures; the bridge failure predates the VM error and persists after it.

Troubleshooting already performed (all unsuccessful for the bridge issue)

1. Started multiple brand-new sessions (both desktop app and web)
2. Fully restarted the desktop app numerous times (including clean File→Exit)
3. Restarted the computer
4. Ran Windows Apps → Repair on the Claude desktop app
5. Verified desktop app is open, computer awake, same account on both surfaces
6. Verified trusted folders are still configured (screenshot)
7. Added a second trusted folder pointing directly at the affected subfolder
8. Attached the folder explicitly via "Add folder" in a desktop-app session
9. Troubleshot with Fin (support AI); was told a technician would contact me — no contact after 20+ hours
10. No VPN/firewall/network changes; no Windows or hardware changes preceding the failure

Not yet attempted

• Full uninstall/reinstall of the desktop app (holding as last resort; will preserve %APPDATA%\Claude\logs first)

Why I suspect a server-side cause

• Two months of stable operation, then sudden failure with zero local changes
• Onset roughly coincides with the Cowork remote announcement/rollout
• Intermittent per-session success/failure pattern (handshake-level flakiness, not a config problem)
• Partial file staging (CLAUDE.md only) indicates the connection initiates and then drops

Impact

Complete loss of Cowork's local-file workflow. My book production pipeline (multi-stage chapter refinement against local manuscript files) has been blocked for over 24 hours. Current workaround is manually uploading individual files to chat sessions.

Request

1. Escalation to a human technician (Fin ticket opened ~2026-07-09; no follow-up received)
2. Confirmation whether a bridge/remote-infrastructure change was deployed in the affected window
3. Guidance on whether debug logs show the handshake failure (logs preserved from %APPDATA%\Claude\logs; happy to attach)

Attachments available on request

• Screenshot of Trusted Cowork folders settings
• Screenshot of the "Failed to start Claude's workspace" error
• Desktop app debug logs

coworkd-user.log
cowork-service.log
main.log
main1.log
mcp.log
mcp-info.json
mcp-server-Affinity.log
unknown-window.log
cowork_vm_node.log

What Should Happen?

Not sure what to put since is for cowork

Error Messages/Logs

Steps to Reproduce

Happens every time I try to do anything in the desktop app with cowork.

Claude Model

_No response_

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Not sure what to put since is not a code issue

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

_No response_