[BUG] /remote-control times out when re-attaching a session that was previously attached

Status Open
Reported on v2.1.233
Maintainer reply None cached
Activity 1 comment · opened Aug 18, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Version: 2.1.233 (Claude Code), Windows 11 Pro 26200

What happens
A desktop session was attached to the mobile app via /remote-control and worked.
It later showed "Disconnected · Remote control" in the mobile app. Running
/remote-control again in that same session fails with:

Remote Control failed to connect: Remote Control connect timed out

On a later attempt it produced no output at all.

Why it is not the machine

  • The mobile app still shows the full transcript of that session, so the

attachment existed and the session is known to the service.

  • claude remote-control --spawn same-dir from a plain console connects fine

from the same machine, seconds before and after the failure, and shows
"Connected". So networking, DNS and auth are all working.

  • Every remote-control process was killed and the device slot left free for

75+ seconds before retrying, so nothing local held the connection.

  • Both candidate workspaces report hasTrustDialogAccepted = true.

Expected
/remote-control re-attaches the current session, as it did originally.

Actual
Times out, or does nothing. The only way to reach the laptop from mobile is a
standalone claude remote-control daemon, which creates NEW empty sessions
rather than attaching the one you are working in.

Impact
No way to continue an in-progress desktop conversation from the phone, which is
the main reason to use the feature.

<img width="672" height="1496" alt="Image" src="https://github.com/user-attachments/assets/81e06237-3055-44db-84fa-a6e1ab4b660e" />
<img width="672" height="1496" alt="Image" src="https://github.com/user-attachments/assets/0022fa3a-85f1-46e3-8dc0-442cb820a6f0" />
<img width="672" height="1496" alt="Image" src="https://github.com/user-attachments/assets/9a2b2ad9-ab7b-4c3e-b34d-4daf532a13e0" />
<img width="672" height="1496" alt="Image" src="https://github.com/user-attachments/assets/45cdf767-eaf0-47db-b063-98fb82605b37" />
<img width="672" height="1496" alt="Image" src="https://github.com/user-attachments/assets/cb58deac-08f2-4294-9017-b956f60ac891" />
<img width="672" height="1496" alt="Image" src="https://github.com/user-attachments/assets/0a52b77d-ddfd-4b45-a1fe-bdad9feb59a2" />
<img width="672" height="1496" alt="Image" src="https://github.com/user-attachments/assets/8fc2b034-c97c-45ba-a0f7-ae966e3a0ead" />

What Should Happen?

Running /remote-control in a session that was previously attached to the mobile app should re-attach it, so the conversation continues on the phone with its existing history. It fails with "Remote Control failed to connect: Remote Control connect timed out". On a later attempt it produced no output at all. The session stays "Disconnected · Remote control" in the mobile app.

Error Messages/Logs

Remote Session timeout

Steps to Reproduce

  1. In a desktop Claude Code session, run /remote-control. It attaches and the session appears in the mobile app.
  2. Leave it until the mobile app shows "Disconnected · Remote control". The session's transcript is still visible on the phone.
  3. Run /remote-control again in that same session.
  4. It times out. Retrying does nothing.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.233 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Not a local problem:

  • claude remote-control --spawn same-dir from a plain console connects fine from the same machine seconds before and after, showing "Connected". Networking, DNS and auth all work.
  • All remote-control processes were killed and the device slot left free for 75+ seconds before retrying, so nothing local held the connection.
  • Both candidate workspaces report hasTrustDialogAccepted = true.
  • The mobile app still shows the full transcript of the session, so the service knows about it.

Impact: no way to continue an in-progress desktop conversation on the phone. A standalone remote-control daemon only creates new empty sessions instead of attaching the one you are working in.

Version: 2.1.233 (Claude Code), Windows 11 Pro 26200

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗