Dispatch session transport stuck in "starting" state, never reaches QUEUED (AcknowledgeWork 409 loop)

Status Open
Reported on v2.1.215
Maintainer reply None cached
Activity 0 comments · opened Jul 19, 2026

Description

Dispatching a task from the mobile app to a desktop session repeatedly fails with "Desktop appears offline", even though the desktop app is running, has internet connectivity, and was restarted.

What's happening (from local main.log)

Every new session created against the same backend environment gets stuck:

  • Backend keeps returning:

AcknowledgeWork: Conflict (409): Work item cse_01M5s9NQS4swDD7yA3FJvgqt must be in QUEUED state to acknowledge. Current state: starting.

  • Client retries the transport reconnect loop (6 attempts, exponential backoff), hits the cap, triggers a backend redispatch (2 attempts), then gives up:

Cap-redispatch budget exhausted for cse_01M5s9NQS4swDD7yA3FJvgqt (2); transport stays dead until app restart or system resume

  • This happened identically across at least two different session IDs (cse_01HJ8jFGLorqzvngKi6ax5K2, cse_01M5s9NQS4swDD7yA3FJvgqt), both mapped to the same environment: env_015Jzh5n2NGaZZW8cAB3LB6H.
  • Restarting the desktop app did not resolve it — a freshly created session immediately hit the same stuck-starting state on the same environment.

Environment

  • Claude Code binary: 2.1.215 (Windows desktop app)
  • OS: Windows 10

Expected

Dispatching from mobile should either connect to the desktop session or fail with a clear, actionable error — not silently loop and die while the desktop app is up and reachable.

Sample request-ids for reference

req_011CdBB5sbn4M8U4JezgB2ja, req_011CdBB5ZPQFeW6RqUKuV5Bc, req_011CdBB4LZhXLHySWr4njW4v

View original on GitHub ↗