Can Claude Code Run 24/7 on a Remote Mac? 2026 Setup Guide

Current status

Why people search “remote 24/7” in September 2026

Not because Claude Code suddenly moved into someone else’s cloud. Anthropic shipped Remote Control as a first-class feature: start a task at the desk, then pick it up on a phone or another browser. A lot of readers hear that and assume the lid can close, or the machine can power off. The docs say the opposite. The session keeps running on the Mac that already started Claude Code. If that laptop sleeps, work pauses and only reconnects when the box wakes. Read it in the Claude Code Remote Control documentation.

Tasks also got longer. A session is no longer “fill in a function.” It can hold tests, a refactor, MCP tools, and sub-agents for tens of minutes. Closing the lid is an intentional kill. And iOS / macOS work still sticks to real Apple hardware: a Linux VPS can host the CLI, not Xcode, the simulator, or signing.

So the keyword is worth the click when you need to separate three ideas: remote viewing, remote execution, and a host that never sleeps. If you are still choosing an agent stack rather than a host, start with Claude Code, Cursor, Prime Agent, OpenHands: 2026 Guide and decide whether you even need an always-on Mac.

Five ways: local, Remote Control, your mini, a remote Mac, CI

Pick a path from the pain, not from product names. All five can “run Claude Code.” Only the last three have a chance of surviving after you shut the notebook.

Path 1: leave the laptop on. Simplest, and the one most often sold to yourself as 24/7. If the lid stays open and macOS never sleeps, Claude Code can run all night. The same machine is also your display, keyboard, and carry-on. Close the lid, walk into a subway, or let the system sleep, and the job stops. Fine for “finish this session this afternoon.” Useless for “I will look at the diff tomorrow.”

Path 2: laptop plus Remote Control. This is the official answer for “I walked away from the keyboard, but the Mac is still on the desk.” Phone and browser are windows. MCP servers, the repo, and signing identities stay local. It solves “approve one prompt from dinner,” not “stuff the laptop in a bag.” Team and Enterprise need an owner to flip the admin toggle. API keys do not work.

Path 3: a Mac mini that stays powered at the desk or at home. For a solo developer, this is the closest self-hosted 24/7. The box can stay awake; you SSH or use screen sharing. You also own the public IP, dynamic DNS, power cuts, and disk. When you enable Remote Login, follow Apple’s “Allow a remote computer to access your Mac” and expose only the accounts you need. Do not hang an admin password on the open internet.

Path 4: a remote or cloud Mac. The difference from path 3 is not “can Claude Code run.” It is whether you still want to own power, network, disks, and account offboarding. Shutting the laptop, leaving an agent on tests overnight, or letting a teammate use one pinned Xcode is when this path starts to look like a buying decision. If you are still weighing “buy a Mac this year” against “rent one you can SSH,” the hardware calendar in When Will the 2026 Apple Fall Event Take Place? What New Macs Are Coming? is the other half of that call.

Path 5: hosted CI. Xcode Cloud or a GitHub macOS runner is for shipping and tests. It is not a place to sit inside a Claude Code prompt. Do not read “CI can queue at 3 a.m.” as “an interactive Claude Code session can run 24/7.”

Remote Control and SSH + tmux are not the same job

The two tools show up in the same SERP and solve different problems. Remote Control lets a signed-in claude.ai or Claude app attach to a process that is already running. SSH lets you log into another macOS box and start the process there. 24/7 needs the process to change machines, not an extra viewport.

The official limits are blunt. Close the terminal, quit VS Code, or stop the claude process, and the remote session goes offline within seconds. To survive an SSH disconnect, the session has to live in tmux or screen. Server mode also gives up after about ten minutes of network loss and you have to run claude remote-control again. That is in the Limitations section of the same Remote Control page, not a forum rumor.

Auth splits the same way. claude setup-token and CLAUDE_CODE_OAUTH_TOKEN are for CI and scripts. They last a long time and cannot open Remote Control. If you want the phone to steer the session, you need a full-scope claude.ai login, not an API key. Check the Claude Code authentication notes before you mint a token on a headless box and then wonder why claude remote-control asks for a full-scope login.

One more name collision: Claude Code on the web. It shares the claude.ai/code UI with Remote Control, but the session runs on cloud infrastructure. It does not see the certificates, DerivedData, or local MCP servers on your remote Mac. Signing an iOS build, using the keychain, or hitting an internal MCP still means the process has to sit on real macOS.

What to prepare before you start

List the environment once so you do not stall on a login page halfway through.

• A macOS host that will not auto-sleep: a mini that is not your laptop, or a remote Mac.
• Remote Login on, and a working SSH path from your daily machine.
• Claude Code CLI installed on that host, not pointed at a network mount from the laptop.
• tmux or screen on the host; the first command after login should attach a session.
• For Remote Control: a Pro, Max, Team, or Enterprise plan and a finished claude.ai login. Team / Enterprise also need the admin toggle.
• At least one successful claude run in the project directory that accepted workspace trust. Remote Control will not trust your home directory.
• Do not leave ANTHROPIC_API_KEY as the only auth, and do not expect Remote Control behind a custom ANTHROPIC_BASE_URL.

Do not size RAM from “the CLI can start.” 16GB is usually enough for Claude Code and a mid-size repo. If Xcode, a simulator, or two-plus agents share the box, 24GB is less likely to shove a spike into swap. That is capacity planning, not a bake-off score.

Keep the session alive on a remote Mac

Assume SSH already works. The goal is not “it chats.” The goal is “the process is still there after the laptop disconnects.”

1. Turn sleep off first

System Settings → Battery / Power Adapter: stop automatic sleep. The display can go dark; the system must stay awake. If the host sleeps, tmux cannot save an in-flight model request.

2. Enable Remote Login and prove it

System Settings → General → Sharing → Remote Login. Grant only the users you need. From the laptop:

ssh user@mac-host.local
uname -m
sw_vers

If you see architecture and an OS version, continue. If you do not, fix the firewall, the VPN, and “same iCloud user only” before you install Claude Code.

3. Enter tmux on the first command

tmux new -A -s claude
# then install or start Claude Code
# leave: Ctrl-b then d
# next time: tmux attach -t claude

The official sentence collapses to one habit: if you want the session after SSH dies, put it in tmux or screen. Skip this and every Remote Control trick is makeup on a process that dies with the SSH shell.

4. Log in and start on the host

Inside tmux, cd into the project and run claude. Use /login through claude.ai. On a headless box you can mint claude setup-token on a machine with a browser and use that token only for scripts or CI. If you also want phone steering, come back and complete a full-scope login. For a daily 24/7 interactive session:

cd ~/Projects/ios-app
claude --remote-control "night-agent"

That leaves a terminal you can type in and also exposes the session to claude.ai / the Claude app. If the Mac should only be a server and you type entirely on the phone, use claude remote-control. Both modes require that process to stay up.

5. Fail the link on purpose

Do not trust “it should still be there.” Walk this list:

• Detach tmux and close the laptop SSH window.
• SSH again, tmux attach -t claude — same session, same scrollback.
• If Remote Control is on: after the SSH window dies, the phone still shows the session online.
• Sleep the host for two minutes, then wake it: the session should pause and resume, not pretend it never stopped.
• Run tmux ls. “No server” means the last start was never inside tmux.

Drops, sleep, and login failures

The session vanished. Run tmux ls first. No server means it was never attached, not that tmux “lost” it. Make tmux new -A -s claude the first command after every login.

Remote Control wants a full-scope login. You probably used setup-token or CLAUDE_CODE_OAUTH_TOKEN. Unset those, run claude auth login, pick claude.ai. If ANTHROPIC_API_KEY is still in the environment, clear it first.

The phone goes offline after you close the lid. That is expected. Remote Control reconnects when the host returns; it does not keep editing files on a sleeping notebook. Leaving the house means the process has to live on a Mac that stays awake.

Server mode exits by itself. If the host is awake but the network is gone for about ten minutes, claude remote-control gives up. Interactive mode keeps retrying locally. SSH back into tmux and start server mode again.

Custom gateway or Bedrock. Remote Control wants api.anthropic.com. If you set ANTHROPIC_BASE_URL, Bedrock, Vertex, or an enterprise gateway, treat Remote Control as unavailable and stay on SSH + tmux in the terminal.

A permission dialog nobody clicks. Remote Control can forward some prompts to the phone, not every dialog. For long unattended runs, tighten permission mode to what you can auto-approve, and assume a human still has to look once.

Who should move Claude Code off the laptop

FAQ