[BUG] /remote-control times out when re-attaching a session that was previously attached
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-dirfrom 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
- In a desktop Claude Code session, run /remote-control. It attaches and the session appears in the mobile app.
- Leave it until the mobile app shows "Disconnected · Remote control". The session's transcript is still visible on the phone.
- Run /remote-control again in that same session.
- 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-dirfrom 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
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗