Remote Control: Dispatch stuck on "Brewing..." - no response from spawn session (Windows 11)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/37605
2. https://github.com/anthropics/claude-code/issues/36008
3. https://github.com/anthropics/claude-code/issues/37357

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

I'm getting the same thing on multiple platforms over multiple accounts. It just does "brewing" and all that dumb stuff then times out then tries again over and over again. Sad thing is it's eating up usage on both my accounts and this has been going on for 3 days. I haven't received a legit reply from Claude code this whole time.

Thanks for flagging the related issues. I can confirm this is not an isolated case.

Additional context:

• The claude remote-control terminal shows absolutely no activity when messages are sent from either the mobile app or browser
• Messages are marked as "read" on the mobile app, suggesting the server receives them but fails to relay to the local CLI
• Tested on a fresh Node.js installation (v24.14.0) with no proxy or VPN

Looking forward to a fix. This feature is critical for mobile/remote workflows.

Same issue on macOS (v1.1.9310)

Dispatch receives messages and marks them as "✓ Read" from the mobile app, but Claude never responds. Affecting me on macOS, not just Windows.

Technical findings after diagnostics:

• bridge-state.json correctly records processedMessageUuids for each incoming message
• A local session file is created in local-agent-mode-sessions/ but the messages array is empty — Claude is never actually invoked
• No background Claude agent process is spawned to handle Dispatch messages
• Feature flags wakeScheduler and operon show as "unavailable" in the app process flags — possibly the root cause
• localSessionId: local_ditto_1c0b5ec0-0c06-4005-a130-a88271bdae25
• remoteSessionId: cse_01M6yhdgNYgXqNHy8UoyBp4b

Tried resetting bridge-state.json and restarting the app multiple times — no change.

@chauletb Thanks for the detailed investigation! The finding about wakeScheduler and operon feature flags showing as "unavailable" is very helpful. It seems like a server-side issue that we can't fix on our end. Hopefully the team can look into this soon.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

Remote Control: /rc loops "connecting… → disconnected", never reaches Connected (Windows 11, Pro)

Bug Description

Running /remote-control (bare command, fresh session) never completes the
handshake. It shows /rc connecting… then falls back to
Remote Control disconnected, in a loop. It never reaches Connected/Attached.
As a result, messages sent from the mobile app / browser are marked "read" but
never reach the local session — the terminal stays completely silent.

Environment

• OS: Windows 11
• Claude Code: 2.1.175
• Plan: Claude Pro
• Model: Fable 5
• Auth: OAuth (firstParty), logged in successfully

Steps to Reproduce

1. Start a fresh claude session
2. Run /remote-control (bare, no session name)
3. Output shows /rc connecting…
4. Shortly after: Remote Control disconnected
5. Repeats on every retry — never reaches Connected

What I Ruled Out

• Claude Code is on the latest version (2.1.175)
• Test-NetConnection api.anthropic.com -Port 443 → TcpTestSucceeded: True
• No ANTHROPIC_BASE_URL set at Process / User / Machine level
• No stray ANTHROPIC_API_KEY
• PATH intact (System32 present)
• No outbound firewall rule blocking node.exe
• Fresh session, no stacked / ghost Remote Control sessions
• Tested on Wi-Fi, 4G and 5G
• Tested from Android app, desktop app, and browser — same result

Expected Behavior

/remote-control should reach Connected/Attached and deliver remote
messages to the local session.

Actual Behavior

/rc connecting… → Remote Control disconnected, looping. Remote messages
never delivered. Terminal shows zero activity.

Note

Remote Control launched for Max first, with Pro access rolling out gradually and
still in research preview. Possibly the Pro-tier handshake isn't fully enabled
server-side for this account?

Related: #38049 (same family of symptom on Windows).

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.