claude.ai/code web UI sessions fail to connect to local Desktop app — "Retry connection" after "Environment in use"

Resolved 💬 4 comments Opened Mar 18, 2026 by chris544460 Closed Apr 15, 2026

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

  1. Have Claude Desktop app running and connected to claude.ai
  2. Open claude.ai/code in Chrome
  3. Web UI correctly shows the local machine name and project
  4. Type any prompt and press Enter
  5. An "Environment in use" dialog appears, naming a previous session
  6. Click either "Keep current session" or "Start new session"
  7. 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

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗