I already run OpenClaw on my server. It handles the useful day-to-day layer: Telegram conversations, scheduled jobs, notifications, research, summaries, and the accumulating collection of small automations that make a personal assistant worth having.
So at first glance, Claude Code Remote Control looked redundant. Why put another AI interface on the same box when I can already talk to OpenClaw from my phone?
Because they solve different problems.
OpenClaw is my normal control plane. But when an OpenClaw update breaks that control plane, I need an independent way back in. In the past that meant SSH from a laptop with the right keys. Fine at a desk; useless when the laptop is shut, elsewhere, or simply not with me.
Claude Code Remote Control fills that narrow but important gap. It leaves a persistent Claude session on the server and gives me a phone interface to it. That makes it a fallback console for the moments when the assistant I normally use to operate the system is the thing that needs fixing.
I learned the value of an external recovery path the hard way during an OpenClaw update failure. An assistant that cannot help repair itself needs a separate route into the machine. Ideally one that does not depend on finding a laptop first.
Two layers, not competing assistants
The division of labour is straightforward:
- OpenClaw is the conversational and automation layer. It is where I normally work, from Telegram, with the routines and context I have built up.
- Remote Control is the persistent operator console. It is there for server-side inspection, maintenance, recovery, and tasks that are easier when Claude can work directly in the environment.
Most days I should not need the second layer. That is exactly why it is useful. Backups, recovery consoles, and spare keys are boring right up until they are not.
Remote Control is not “coding on a phone.” That still sounds like a punishment. The phone is a way to give a bounded task to a Claude process already running next to the files, logs, tools, and services it needs to inspect.
The basic shape
Claude Code runs on the server, authenticated with a Claude.ai subscription, and Remote Control exposes a session that can be opened from a phone or a browser.
The essential command is:
claude --remote-control
The command is a flag, not a separate subcommand. Claude Code needs to be logged in through Claude.ai OAuth; an API-key-only setup is not sufficient for this workflow.
The architecture is intentionally simple:
phone or laptop → Claude.ai Remote Control → Claude Code on server → tools, logs, services and project files
The screen is disposable. The working process is not.
Why tmux still matters
The Claude process must not be a child of my current SSH connection. If it is, losing Wi-Fi or closing the laptop can take the remote session down with it.
That means tmux belongs on the server, not around the SSH client on a laptop. Claude Code also needs a PTY in this mode, and tmux supplies one. As a useful side effect, I can attach to the running pane over SSH when I want to inspect the same live session in a proper terminal.
The simple manual version is enough to test the idea:
tmux new -s claude-remote
claude --remote-control
Detach from tmux and the process remains alive after the SSH session ends. But “alive until the next reboot” is not a serious fallback plan.
Making the fallback survive a reboot
The production version is deliberately restart-proof. I use a user-level systemd service that starts at boot and launches a dedicated tmux server. The tmux pane runs a small supervisor loop, which starts Claude Code Remote Control again if the Claude process exits.
There are four details worth preserving in any similar setup:
1. Enable user lingering
A user service normally exists only while that user has an active login session. Enable lingering so the service can start at boot even when nobody has logged in interactively. Without it, the unit can look perfectly configured and still fail at the moment it is supposed to save you.
2. Let systemd supervise tmux, and the pane supervise Claude
systemd can restart a failed tmux server. It cannot see that Claude has quietly exited inside an otherwise healthy tmux pane. The launcher inside the pane therefore needs its own restart loop.
That loop should use exponential backoff. A normal exit can restart promptly, but a bad login or configuration must not hammer the service every second forever. This is a tiny bit of defensive engineering that prevents a broken recovery path from becoming a noisy one.
3. Use a dedicated tmux socket
The managed session should not share a tmux server with ad-hoc terminal work. A dedicated socket means the service can stop and restart its own session without killing unrelated panes, and an old manual session cannot quietly interfere with the managed one.
4. Deal with the trust prompt before you need recovery
An unattended first start can stall at Claude Code’s workspace-trust prompt. The service may still report itself as healthy because tmux is running, while Remote Control never actually registers. Accept the trust prompt deliberately during setup and test a headless start afterwards. This is the kind of failure that wastes time precisely because every status indicator looks reassuring.
What survives—and what does not
The service restores a new Remote Control session, not an immortal conversation. A reboot kills the old process, so its live context is gone. Claude Code transcripts remain available locally and can be resumed deliberately, but automatically continuing whichever conversation happened to be latest is a bad recovery design.
After a reboot, I want a clean, known-good operator console. I can choose whether to resume an old thread once I know what I am investigating.
That distinction matters. Persistence of access is valuable; persistence of accidental context is not.
What I will actually use it for
The most valuable use cases are not exotic. They are the jobs that are too operational for Telegram alone, but too small to justify finding a laptop immediately.
1. Recovering OpenClaw when its normal interface is unavailable
Check service status, inspect logs, review what changed, and diagnose an update failure from a separate control path. This is the central reason I set it up. It gives me a route to investigate the assistant without depending on the assistant to be healthy first.
2. Starting incident triage the moment I notice a problem
A missed digest, broken backup, noisy alert, or log anomaly can be handed to the remote session immediately: inspect the evidence, identify likely causes, and leave a concise diagnosis. By the time I return to a proper terminal, I have facts rather than a vague reminder.
3. Reconnaissance before a real maintenance session
Map an unfamiliar repository, compare configuration files, list failing tests, search logs, or trace the delivery path of a scheduled job. The phone starts the read-only first pass; the laptop handles the decisions and edits that deserve more attention.
4. Following long-running work away from the desk
Builds, test suites, data processing, and package operations finish when they please. Remote Control lets me ask what happened, read the error, or queue the next safe diagnostic step from a train or sofa without turning the phone into a terminal emulator.
5. Turning a fleeting automation idea into a concrete plan
“I should automate that” is not a plan. From a phone, I can ask Claude to inspect the relevant scripts and produce a proposal with affected files, risks, and rollback points. The next desk session starts with something reviewable rather than an empty editor.
6. Handing work between phone and laptop without losing the thread
Start a bounded investigation while mobile, then attach to the same tmux session over SSH when the job becomes too detailed for a touchscreen. The working directory, process, and findings are already in place.
Sensible boundaries
Remote access to an agent is useful because it is powerful, which is also why it needs boundaries.
- Start the session in a deliberate workspace, not whatever directory happens to be current.
- Keep normal safeguards around secrets and destructive actions.
- Use auto-approval only where the blast radius is understood.
- Prefer inspection and planning from the phone; review significant changes on a larger screen.
- Treat Remote Control as independent from OpenClaw, not as a shortcut around good operational practice.
The goal is not to give an AI unrestricted access to everything. The goal is to keep one carefully prepared recovery console available when the main control plane has had a bad day.
The real upgrade is continuity
OpenClaw remains the system I use every day. Remote Control is the independent, restart-proof way into the machine underneath it.
That is a modest addition, but an important one. The old recovery workflow began with “find the laptop with SSH keys.” The new one begins with “open the phone and inspect the problem.” For a self-hosted assistant, that is the difference between a clever automation setup and an operationally resilient one.