Claude Code Remote Control Not Working? 3 Causes and Fixes
Remote Control shows a gray icon, or your phone just spins with no output. It's usually not a bug — it's one of three specific things that killed the local process. Here's how to tell which, and what to do about each.
The quick answer
If Remote Control worked yesterday and today it just hangs, the single most likely cause is: your laptop lost network for roughly ten minutes or more, and the Remote Control session timed out and exited. (Source: official docs) That's documented, expected behavior — not a bug. The fix is to go back to the machine and run claude remote-control again.
Remote Control is currently a research preview available on Pro, Max, Team, and Enterprise plans (Team and Enterprise have it off by default until an org owner enables it). (Source: official docs) If that timeout isn't your situation, the table below covers the other two common causes.
Three things that kill a Remote Control session
| Cause | What you'll see | Why it happens |
|---|---|---|
| Network timeout | Icon goes from green to gray; no new output at all, indefinitely | After roughly 10 minutes without network, the session times out and the local claude process exits (Source: official docs) |
| Process killed | Same symptom, but it happened right after you closed a terminal window, quit VS Code, or your laptop went to sleep | Remote Control is a local process. Close the terminal or editor it's attached to and the process dies with it — there's nothing left for your phone to talk to (Source: official docs) |
| Machine still waking up | Spins right after you open the laptop, then reconnects on its own once your machine is back online | The laptop just woke from sleep — Remote Control reconnects automatically when your machine comes back online (Source: official docs) |
Fixes that don't need anything extra
- Just restart it. Go back to the terminal and run
claude remote-controlagain — this covers both the timeout and the process-killed case. - Run it inside
tmuxorscreen. Anthropic's own docs recommend starting Remote Control inside a terminal multiplexer specifically so closing your terminal window doesn't kill the underlying process. (Source: official docs) - Keep the machine from sleeping.
caffeinateon macOS before you leave, or disable sleep in power settings. - Fall back to a phone hotspot if your home or office WiFi drops often — it won't remove the 10-minute timeout, but it cuts how often you actually hit it.
Where these fixes fall short
Wrapping the process in tmux keeps it alive, but your phone doesn't automatically reattach to it — you may still need to run claude remote-control --continue by hand once you're back. Keeping a laptop from sleeping is easy at a desk and awkward on a plane, and closing the lid on most laptops forces sleep regardless of what your power settings say. A hotspot helps with flaky WiFi but does nothing once you're somewhere with no signal at all for more than ten minutes.
If the real goal is "the machine can be off entirely," Remote Control isn't built for that — Anthropic's own docs point you to Cloud sessions instead, which execute on Anthropic's infrastructure rather than your laptop. (Source: official docs) None of the fixes above change that; they all still assume your machine is on.
If what you want is no timeout and no manual restart
Every fix above manages a process that can still die — it just makes that less likely, or makes you the one who has to notice when it happened. If you want a session that survives an arbitrary amount of offline time and reconnects itself without a manual step, that calls for a different architecture, not a longer timeout.
PocketShell is a self-hosted alternative built around that idea: the tmux session on your machine is the source of truth, not the phone's connection to it. Output keeps writing into a server-side ring buffer while you're offline, and reconnecting replays whatever you missed by sequence number instead of depending on the same browser tab or app session staying open — it isn't a network-timeout policy you can tune, it's a different way of tracking what happened while you were gone.
To be clear about what that doesn't solve: PocketShell isn't cloud-hosted either. If the machine running it loses power, your task stops too — same as any self-hosted setup, and unlike the official Cloud sessions above. What it removes is the phone-side flakiness being the thing that kills your session in the first place.