Coding From the Couch
I’ve been using Claude Code heavily for a while now — it’s become my default way of working on projects. So when Anthropic announced Remote Control on February 25th, I was immediately interested. The pitch: start a Claude Code session on your main machine, then pick it up from your phone or any browser. Your code stays local, only the conversation routes through Anthropic’s servers.
The setup is dead simple. Run claude remote-control in your terminal, scan the QR code with your phone, and you’re in. Or type /rc from an existing session. You can even toggle “Enable Remote Control for all sessions” so every session is automatically available remotely — no extra step needed.
And it works. I’ve been using it to keep an eye on longer-running tasks, approve file changes while away from my desk, and even kick off new work from my phone. The idea of starting a coding session from a café or during a commute and having it run against your actual dev environment is genuinely compelling.
But let’s talk about reality.
Disconnects Are the Big One
My main frustration has been disconnects. The connection tends to drop after long idle periods — step away for a while and come back to find your session has timed out. Anthropic’s own docs mention that if your machine loses network for about 10 minutes, the session times out and exits — you have to start a new remote session. But I’ve also seen disconnects triggered by permission prompts that don’t get answered in time, which leads to the next issue.
When it disconnects, reconnecting to the same session can be hit or miss. Sometimes it picks right back up, sometimes you’re staring at a loading state that never resolves. It’s the kind of thing that makes you nervous about leaving a long task running and walking away — which is exactly the use case Remote Control is supposed to enable.
Simon Willison described the early experience as “a little bit janky right now”, and that matches what I’ve seen. It’s a v1 feature, and it feels like one.
Permission Prompts Get Lost
Here’s the more subtle issue, and a major source of those disconnects: Claude Code asks for permission before doing things — running shell commands, editing files, accessing new tools. On a local terminal, you see these prompts immediately and hit y or n. On the mobile remote control, these prompts sometimes don’t surface properly, or there’s enough lag that the session feels stuck. If the prompt goes unanswered long enough, the session can time out entirely.
I’ve had situations where Claude was clearly waiting for me to approve something, but the mobile interface wasn’t showing the prompt. You end up wondering: is it thinking? Is it stuck? Did it finish? The lack of a full terminal view makes this worse — Remote Control shows you the conversation and diffs, but not the raw terminal state. So you’re missing context that would immediately tell you what’s happening if you were sitting at your desk.
For short, well-defined tasks this is fine. For exploratory sessions where Claude is asking questions and requesting approvals frequently, it gets frustrating fast — and you risk losing the session if a prompt slips through.
What You Need to Know Before Trying It
A few practical things I’ve learned:
- Available on all plans: Remote Control initially launched as Max-only, but Anthropic has since expanded it to all plans — Pro, Max, Team, and Enterprise. Team and Enterprise admins need to enable Claude Code in their admin settings first.
- One viewer at a time: Only one remote connection per session. You can’t have it open on your phone and your tablet simultaneously.
- Terminal must stay running: If the process on your main machine exits, the remote session is gone. This isn’t a background daemon — it’s your actual terminal session being shared.
- No raw terminal access: You see the Claude conversation, file diffs, and tool outputs. You don’t get a full shell. If you need to run arbitrary commands, you still need to SSH in.
The DIY Alternative: SSH + tmux + Tailscale
There’s always the classic approach: run Claude Code inside a tmux session, use Tailscale to reach your machine from anywhere, and connect via Mosh for resilient mobile shell access. I’m deliberately not writing a full tutorial here — there are plenty of good guides out there, and I’d rather keep this post focused on Remote Control itself. But if you need reliable mobile access right now, this stack handles disconnects gracefully and gives you full terminal control.
There’s Also a Third-Party Option
Worth mentioning: Happy is a free, open-source mobile client for Claude Code with end-to-end encryption. Install it with npm install -g happy-coder. I haven’t tried it extensively, but it’s there if you want an alternative to both the official Remote Control and the SSH route.
What’s Coming Next
Anthropic is clearly investing in making Claude Code work beyond the desktop. Just this month they started rolling out voice mode — currently at about 5% of users — which would make the mobile experience significantly better. Talking to your AI coding assistant while walking the dog is the kind of future I can get behind.
Claude Code has also been growing fast — reportedly hitting a $2.5 billion annualized run rate as of February 2026. With that kind of momentum, I’d expect the Remote Control experience to improve quickly. The foundation is solid: keeping code local while routing just the conversation through the cloud is the right architecture. It just needs polish.
The Bottom Line
Remote Control for Claude Code is a genuinely useful feature that I’m glad exists. Being able to check on a running task, approve a few changes, or start something new from my phone adds real flexibility to how I work.
But right now, I’d describe it as “useful with caveats.” The disconnects are real, and the permission prompt handling needs work. If you need reliable mobile access today, the SSH + tmux + Tailscale stack is still the more dependable option.
I’ll keep using Remote Control — the convenience when it works is hard to beat. And knowing Anthropic, the rough edges will get smoothed out. Just maybe keep that tmux session running as a backup.