Claude Code Remote Control Keeps Disconnecting? Rule Out Sleep

Mac sleep is one cause of Remote Control disconnects, not the only one. Check it first because it is the one cause you can prove in a minute: if macOS logged a sleep at the moment the session dropped, keep the Mac awake. If it did not, the cause is the process, the network, your login, another device, or a bug that people report on Macs that never sleep.

First checkpmset -g log at the drop time

Sleep dropsReconnect when the Mac wakes

Other dropsNetwork, login, another device

Still openGitHub issue #33041

Two drops, two different causes.The first break in the link sits inside a sleep gap, so keeping the Mac awake fixes it. The second happens while the Mac is awake, and no keep-awake setting will help.

Remote Control drops look the same from the phone whatever caused them: the session goes quiet, or the app says it cannot reach your machine. This page gives an order to work through, built from Anthropic's Remote Control documentation and the public bug reports, all read on October 11, 2026. For what a closed lid does to a session and how to keep one going with the lid shut, see Remote Control with the MacBook lid closed; this page is only about finding out why a session dropped.

The order to check things in

Right means yes, down means no. Each step is cheaper than the one below it, and only the second step has anything to do with sleep. Most people skip straight to the last box; the first two take a minute and often settle it.

Step 1: read the reason Claude Code gives you

Before guessing, look at the terminal on the Mac. Anthropic's docs say that when the connection fails in an interactive session, the Remote Control indicator changes to show the failure, and "Claude Code shows the reason in a notification and adds it to the conversation." Scroll up in the session and look for a line that starts with Remote Control disconnected. If there is one, it names the cause and you can skip to the matching section below.

In server mode (claude remote-control), the docs list --verbose for detailed connection and session logs and --debug-file <path> to write debug logs to a file. Turn them on if the drops repeat.

One warning about what the phone says. A commenter on issue #33041 reports the client showing that the machine "may be asleep or offline" while the Mac and the Remote Control process were both up. Treat that wording as a guess by the app, and check the Mac's own log.

Step 2: rule sleep in or out

Note the time the session dropped, as closely as you can. Then open Terminal on the Mac and run:

pmset -g log | grep -E "Entering Sleep|Wake from" | tail -40

The pmset manual describes -g log as "a history of sleeps, wakes, and other power management events." It needs no sudo. The full log is long, so the grep keeps only the lines that matter. On the MacBook I ran this on today, the lines look like this:

2026-10-11 14:43:28 +0200 Sleep     Entering Sleep state due to 'Maintenance Sleep' ... Using Batt (Charge:65%)
2026-10-11 14:47:32 +0200 Wake      Wake from Deep Idle [CDNVA] : due to ... lid ... HID Activity

Compare the drop time with the log. A Sleep entry at the drop and a Wake entry where the session came back means sleep. A Mac that was awake straight through the drop means you can stop adjusting sleep settings.

How to read it:

The quoted reason says why the Mac slept. A lid close shows up as 'Clamshell Sleep' in my log.
A sleeping Mac still wakes briefly in the background. You will see runs of DarkWake lines followed by 'Maintenance Sleep'. Those are background wakes inside one long sleep. The entry that matters is the first Sleep in the run, and the Wake from line that ends it.
A sleep drop heals itself. Anthropic's docs list this as a feature: "if your laptop sleeps or your network drops, Claude Code reconnects automatically when your machine comes back online." So the sleep pattern is a drop at a Sleep entry and a return, without you typing anything, soon after a Wake entry. Nothing ran in between.

If the times match, the fix depends on why the Mac slept:

Lid open, Mac idle. Claude Code starts caffeinate on macOS while a session is busy, but issue #81832 (open as of October 11, 2026) reports a gap in it that lets the Mac idle-sleep mid-task once the display is off, and says the protection ends about 30 seconds after the session stops being busy. Starting the session as caffeinate -i claude holds one assertion for the whole run. On power, Apple's sleep settings also offer Prevent automatic sleeping on power adapter when the display is off under Battery, Options. Both are free. The details are in what Claude Code's keep-awake covers.
Lid closed. Neither of those survives a lid close, because caffeinate blocks idle sleep, not lid sleep. The options are an external display setup, sudo pmset -a disablesleep 1, or a lid-closed app such as Clamshell for Mac. They are compared in the lid-closed guide.

To see what is holding the Mac awake right now, run pmset -g and read the sleep line, which names the processes preventing sleep, or pmset -g assertions for the full list.

If the Mac was awake across the drop, sleep is not your problem. Keep going.

Step 3: check the process is still running

Remote Control is a local process. Anthropic's docs: "If you close the terminal, quit the Desktop app or VS Code, or otherwise stop the claude process, the session goes offline."

The session is still open: run /remote-control in it to reconnect.
You stopped Claude Code: resume the conversation with claude --continue or claude --resume. If you see "Couldn't reconnect to your Remote Control session", the docs say to run /remote-control to retry.
The Mac is reached over SSH: the docs recommend starting claude inside tmux or screen so it outlives the SSH connection.

Step 4: network changes and outages

The Mac can be awake and still unable to reach Anthropic. The docs describe three separate cases, each with its own limit:

What happened	What Claude Code does	What you see	Fix
VPN or network change, then HTTP 403 answers	Retries for up to three minutes, then disconnects	A reason naming what refused: a network edge, or a proxy, VPN or firewall on your network	Fix that hop, then `/remote-control`
Long outage, interactive session	Retries for as long as the outage lasts	Reconnects by itself when the network returns	None needed
Long outage, server mode	Gives up after roughly 10 minutes; the process exits	No `claude remote-control` process left	Run `claude remote-control` again
Presence heartbeats failing	Disconnects the interactive session	`could not reach the Remote Control server for about 30 minutes`	`/remote-control`

Login. Anthropic's error reference explains that a live connection runs on short-lived credentials that Claude Code renews from your saved claude.ai login. If that login stops being accepted, Remote Control stops, and the transcript shows a line such as Remote Control disconnected followed by Claude.ai login expired and the instruction to run /login, then /remote-control. Your local session keeps running the whole time.

Team and Enterprise. If your organization uses Trusted Devices, the message session expired for trusted-device check means your sign-in is more than 18 hours old; the docs say to run /login or confirm with Touch ID, Face ID or a passkey when prompted. If an admin turns Remote Control off while you are connected, Claude Code disconnects it and does not reconnect on its own.

Another device. Three reasons mean the session changed somewhere else, and the docs say to run /remote-control only if you want it back: another connection took over the session, the session was ended or archived from another device or app, or the server no longer reports it.

An old version. "Remote Control got an unexpected server response" means your Claude Code version could not read the server's reply. Retrying fails the same way; the docs say to run claude update, then /remote-control.

Step 6: the drops that are not your Mac

If you have reached this point, the Mac was awake, the process was running, the network was fine and your login was valid. You are not imagining it. Three reports in Anthropic's own issue tracker describe this, and I read each one today:

#33041, "Remote Control (/remote-control) disconnects frequently". Open, labeled bug, with 15 comments, the latest from September 27, 2026. The reporter had sleep disabled, caffeinate running and a VPN, and still saw drops every few minutes. One commenter saw two machines on separate networks drop within about 45 seconds of each other. Another, on Claude Code 2.1.263 in September 2026, counted 1,343 reconnects in 38 hours on a Mac that never slept, while a plain WebSocket held from the same Mac stayed up. People report the same on Linux and Windows.
#34500, "Remote Control disconnects during active use". Closed on March 18, 2026 as a duplicate of #33041. Mac sleep was disabled and the terminal session stayed alive; only the remote link dropped, during active use.
#50767, disconnects after about two hours. Closed as not planned on May 26, 2026, by the tracker's inactivity bot. The reporter ran caffeinate -dis, chatted continuously from the phone, and lost the session after roughly two hours at least ten times, with no way to recover without touching the Mac. The issue records no fix.

I found no fix or official workaround posted in any of the three threads. What users there say they do:

Reconnect by hand. Run /remote-control again in the session. This is also Anthropic's documented step after a connection failure.
Run inside tmux and use claude --continue after a drop, as one commenter on #33041 does.
Keep a second way in. One commenter uses a remote desktop tool to reach the Mac and type /remote-control again. SSH into a tmux session does the same job.
Update. Most of the reports name older versions. I cannot confirm from the issues that a later release fixed them, so treat an update as a reasonable first try, not a guaranteed fix.

If your case matches, add your Claude Code version and the pmset -g log lines showing the Mac was awake to #33041.

When keeping the Mac awake is the fix

Only when step 2 matched. If your drops line up with sleep and the lid is open, the free options in step 2 are enough and you do not need an app. If they line up with 'Clamshell Sleep', meaning you closed the lid with no external display, the choice is pmset disablesleep with its risks, or a lid-closed app.

Clamshell for Mac is a menu bar app for that last case. While armed it keeps an Apple Silicon MacBook awake and on the network with the lid closed, without sudo or an external display, and it pauses while an external display is connected. It does not detect Claude Code, does not reconnect a dropped session, and cannot fix a network, login or server-side disconnect. If the drops in your log are not sleep, it will not change them.

Clamshell is for the drops that match a lid close: it keeps the Mac awake with the lid shut while armed. Free for 7 days, then $9.99 once.

Download free trial

Apple Silicon, macOS 14+. Notarized by Apple. 3.6 MB. Or buy now, $9.99. Reading this on your phone? Send the Mac download link to yourself.

Frequently asked questions

Why does Claude Code Remote Control keep disconnecting?

There are several causes. The Mac went to sleep, the claude process stopped, the network changed or dropped, the claude.ai login could not be refreshed, the session was taken over or archived from another device, or a bug on the connection path. Users in the open GitHub issue 33041 report drops on Macs that never slept, so sleep is only one of them.

How do I tell if Mac sleep caused the disconnect?

Note the time of the drop, then run pmset -g log | grep -E "Entering Sleep|Wake from" | tail -40 in Terminal. If a Sleep entry sits at the drop time and a Wake entry sits where the session came back, sleep caused it. If the Mac was awake across the drop, look at the other causes.

Does caffeinate stop Remote Control from disconnecting?

Only when idle sleep was the cause. caffeinate holds off idle sleep with the lid open. It does not stop lid-close sleep, and it does nothing for network, login or server-side drops. Two of the GitHub reports describe disconnects with caffeinate running.

How do I reconnect Remote Control after it drops?

After sleep or a network drop, Anthropic's docs say Claude Code reconnects on its own. If it does not, run /remote-control in the session. In server mode, run claude remote-control again if the process exited. If you stopped Claude Code, resume with claude --continue or claude --resume.

Can I reconnect from my phone without touching the Mac?

Not when the connection has failed on the Mac side. Anthropic's documented fix is to run /remote-control on the machine, and commenters in issue 33041 ask for a way to recover from the phone. Users there work around it with a remote desktop tool or tmux over SSH.

Will keeping the Mac awake fix every Remote Control disconnect?

No. It fixes the drops that line up with a Sleep entry in the power log. A keep-awake command or app cannot fix a network change, an expired login or a server-side drop.

Related guides

Sources checked October 11, 2026: Anthropic's Claude Code docs for Remote Control and the error reference, GitHub issues #33041, #34500, #50767 and #81832 in anthropics/claude-code, the macOS pmset and caffeinate manual pages, and Apple's sleep settings guide. Issue states and counts are as of that date. The issue comments are user reports, not confirmed diagnoses. Remote Control changes often; check Anthropic's current docs before relying on a detail. Clamshell is an independent app, not affiliated with or endorsed by Anthropic. Claude and Claude Code are trademarks of Anthropic.