claude-code - 💡(How to fix) Fix Cowork/Dispatch: backend drops env/session records, UI shows misleading 'Another device connected' / 'Desktop offline' / 'Session can't be created' [2 comments, 3 participants]

Subject: Cowork/Dispatch broken — backend dropping environment and session records

Summary

Cowork/Dispatch unusable since approximately 07:58 local on 2026-04-15. Backend exhibits two cascading failure modes:

1. /v1/environment_providers/private/organizations/<org>/environments returns HTTP 503 "upstream connect error ... reset reason: overflow" in a tight retry loop. 81 failures logged between 07:58 and 12:18 local.

2. Even after 503s cleared (last 503: 12:18:15 local, endpoint has been healthy since), the sessions API drops newly-created records within ~15 minutes. Sessions-bridge creates a session, polls successfully for a short window, then gets HTTP 404 on reconnect and enters a retry loop manifesting as "This operation was aborted" errors.

3. Registration-level aborts on /v1/environments/bridge have been happening intermittently since 11:40 local, in parallel with the 503s.

The Dispatch UI surfaces these backend failures as three different misleading user-facing errors that oscillate as the client retries:

• "Another device is connected / A Cowork agent is already running on Mac"
• "Session can't be created"
• "Desktop offline"

None of these reflect actual local state — local Claude desktop is healthy, VM boots cleanly, only one device is registered.

Specific evidence

Organization UUID: 72d1aee8-3105-4951-92b2-065635bf4a8e

Ghost environment (404): env_01MQ5ve5F9U8Tawov9uuoi8f

• Returned 404 "Environment ... not found" at 11:16:30 local
• Client was in a retry loop against this dead record when 503s started

Ghost session (404): session_01GMhrH7s4qGrmH5U36bMYxd

• Successfully created at 12:26:10 local
• Returned 404 at 12:41:55 local (~16 minutes later)
• Client is still retrying against it

Failing endpoints: GET /v1/environment_providers/private/organizations/{org}/environments → 503 overflow (cleared since 12:18:15) GET /v1/environment_providers/private/organizations/{org}/environments?limit=100&included_worker_types=cowork → 503 overflow (cleared since 12:18:15) POST /v1/environments/bridge → Intermittent "aborted" + Failed with status 503 GET /v1/sessions/session_01GMhrH7s4qGrmH5U36bMYxd → 404 (record GC'd)

Envoy reset reasons observed: overflow (most common), connection timeout, connection termination, fault filter abort

Error counts (between 07:58 and 12:28 local on 2026-04-15): 81 occurrences of 503/overflow on the environments endpoint ~10 registration failures on /v1/environments/bridge with "aborted" Ongoing poll error loop on /v1/sessions/* with "aborted"

Local state

• Claude desktop 1.2581.0 on macOS, Model MacBook Neo (Mac17,5)
• VM healthy, boots in ~6.5s, cowork_vm_node reports CONNECTED
• Only one device registered; no other Mac logged in; all other sessions logged out from account settings before troubleshooting began
• Cleared renderer LevelDB (IndexedDB, Local Storage, Session Storage, Cache, Code Cache) to rule out stale client-side env references — did not resolve the issue, confirming it's server-side
• ant-did device ID untouched

Requested action

Please check the health of the environment-provider and sessions services for this organization. Specifically:

• Is there a circuit-breaker or quota tripped for this org?
• Why are newly-created environment/session records being dropped from the sessions API within minutes? Looks like eventual-consistency leak or premature GC.
• The overflow reset reason suggests the upstream cluster was out of capacity earlier today; has it been fully restored?

I am happy to provide full log excerpts from ~/Library/Logs/Claude/ — main.log, claude.ai-web.log, and cowork_vm_node.log all contain relevant evidence.