claude.ai/code web UI sessions fail to connect to local Desktop app — "Retry connection" after "Environment in use"
Bug Description
Sessions created from the claude.ai/code web UI fail to execute tools on the local machine. The web UI shows the correct device name and project ("<my-macbook> omni"), the model thinks server-side (cycling through "Pontificating…", "Cogitating…", "Germinating…"), but the local Desktop app never receives the session request. The session permanently shows "Retry connection."
Environment
- Claude Code CLI: 2.1.78
- Claude Desktop App: 1.1.5749 (updated to 1.1.7464 during debugging)
- Claude Code SDK in Desktop: 2.1.64
- OS: macOS 15.1 (24B83), Apple Silicon (arm64)
- Plan: Max
Steps to Reproduce
- Have Claude Desktop app running and connected to claude.ai
- Open
claude.ai/codein Chrome - Web UI correctly shows the local machine name and project
- Type any prompt and press Enter
- An "Environment in use" dialog appears, naming a previous session
- Click either "Keep current session" or "Start new session"
- The session shows server-side thinking text but displays "Retry connection" — tools never execute locally
Repeated across 5+ attempts, including after fully restarting the Desktop app (quit → relaunch). The "Environment in use" dialog chains — each new session reports the previous web session as the blocker, even after the Desktop app restarts with existingSessions=0.
Diagnostic Findings
Desktop app logs (~/Library/Logs/Claude/main.log) show zero activity from web-initiated sessions:
After restarting the Desktop app at 16:26, initialization is clean:
[LocalSessionManager] Initialization succeeded — existingSessions=0
[LocalAgentModeSessionManager] Initialization succeeded — existingSessions=0
But when sessions are created from the web UI at 16:28+, there are no corresponding LocalSessions.start entries in main.log. The log goes completely silent after initialization. The Desktop app never receives the session request.
For comparison, sessions created from the Desktop app's own UI at 15:48 work perfectly:
LocalSessions.start:
Starting local session local_6b38d429-... in <cwd>
Mapping internal session local_6b38d429-... to CLI session 41d97d42-...
Terminal sessions (claude --remote-control) also work fine — they bypass the web→Desktop bridge entirely and create local .jsonl session files as expected.
The VM module loads but never boots after restart:
[VM] Loading @ant/claude-swift module...
[VM] Module loaded successfully
[warm] VM SHA matches current version, skipping
No [VM:start] or [VM:steps] entries follow. The VM booted successfully earlier in the day (13:29) but does not restart after the app relaunch.
Network: Desktop app maintains 2 ESTABLISHED TCP connections to Anthropic servers. Connections appear alive but no session commands are received.
Expected Behavior
Clicking "Start new session" from claude.ai/code should terminate any stale session, spawn a new local Claude Code process via the Desktop app, and connect the web UI to it — similar to how the Desktop app's own "New session" button works.
Actual Behavior
The web UI and Desktop app are disconnected. The server-side model runs (generating titles, thinking) but tool execution requests never reach the Desktop app. Zombie sessions from previous attempts block new ones in an infinite chain.
Related Issues
- #26305 — Claude Code Desktop App Chrome Extension Connection Failure
- #26292, #23539 — Related connection issues
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗