I wanted to pull out my phone on a train in Japan, reconnect to a dev session running on my Mac at home, and keep working. That does not seem like such a strange thing to want anymore. But getting it to work reliably from a phone without blowing up my existing setup took more work than I expected.
And then, right around the time I got it working, Claude Code shipped Remote Control and Dispatch. More on that later.
Why I Didn't Just Use Tailscale
If someone told me they wanted private remote access to their personal machine, I would probably tell them to use Tailscale and move on with their life. It is a great tool. For plenty of people it solves the whole problem.
But my situation was a little stranger than that. My Mac runs a work VPN, and I did not want to mix personal and company Tailscale accounts on the same machine. I did not want to expose my home network to inbound connections from the public internet. And because I planned to use this from my phone, often on mobile data between Wi-Fi networks, I needed the connection to survive the kind of interruptions that kill a normal SSH session.
I could easily work around any one of those constraints alone. Together, they ruled out the cleaner-looking options. The remaining setup looks less elegant on a diagram, but it fits those constraints.
The Shape of the Thing
The final setup forms a chain, and each link exists for a specific reason:
flowchart LR
phone[Phone]
mosh[mosh]
vps[VPS]
reverse[reverse SSH]
mac[Mac]
tmux[tmux]
tools[Claude Code]
phone --> mosh --> vps --> reverse --> mac --> tmux --> tools
My phone connects to a small VPS using mosh, which covers the part of mobile networking that plain SSH struggles with: changing IPs, switching between Wi-Fi and cellular, and recovering from drops without leaving you staring at a frozen cursor. Only the VPS has a public address. My Mac reaches it through an outbound reverse SSH tunnel, which means the Mac never needs to accept inbound traffic from the internet at all. And tmux on the Mac turns the whole thing from a fragile connection into a persistent session I can detach from and come back to later.
That last part surprised me. Once the session itself became durable, I could return to work already in progress instead of reconnecting from scratch.
Where It Actually Broke
Most of what I learned came from the failures, not the original plan.
The reverse tunnel could go half-dead after sitting idle. Port 22 continued listening on the VPS. The connection looked fine. But the session behind it had gone stale, so jumping to the Mac would just hang. Fixing it meant treating liveness as a real concern on both sides: SSH keepalives from the Mac, autossh to rebuild the tunnel when it dropped, and a VPS-side script that checked whether localhost:22 actually responded before attempting the jump.
That jump script exposed another failure mode. The first version tried to SSH into the Mac every time I connected to the VPS. It worked while the tunnel stayed up, but after the tunnel dropped it left me with a hanging shell and no feedback. The better version checked the port first, used a short connect timeout, and dropped me into a normal VPS shell as a fallback. Small change, but it turned an unreliable experience into one I could trust.
Then tmux caused another problem. A session created under one terminal environment did not always attach cleanly from another. In my case, xterm-ghostty on the Mac caused problems when the same session got reattached from a mobile client. Setting a more portable default terminal type fixed it and reminded me that session portability depends on the assumptions baked into it.
None of these looked dramatic. Together, these half-solved problems can turn a clever setup into one you stop using after a week.
And Then the Tooling Caught Up
Right around the time I had this working reliably, Anthropic shipped two features that cover a lot of the same ground.
Remote Control lets you continue a local Claude Code session from your phone or any browser. It runs on your machine (your filesystem, your tools, your project config) with the phone just acting as a window into that session. No port forwarding, no VPS, no reverse tunnel.
Dispatch goes further. You message a task from your phone, and it spawns a session on your Mac to handle it. You do not even need to have a session running already.
So did I waste my time? Honestly, I do not think so. Remote Control allows one connection per session and times out after about ten minutes of network loss, an awkward limit on spotty mobile data on a rural train line. My setup survives longer outages because mosh and autossh handle exactly that. And the VPS gives me a general-purpose foothold beyond Claude Code, including a shell when I need one.
If I started fresh today with a stable connection and needed only Claude Code access from my phone, I would try Remote Control first and probably never build any of this.
The Lesson Worth Keeping
I have run into the same trade-off with infrastructure, AI tooling, and the house we built last year. An initial design can look clean before details such as an unreliable connection or an existing work VPN force it to change. The result may look stranger, but each piece addresses a constraint.
Tools also catch up, and the constraints can change. The setup I built still helps me, but I would not recommend every part of it to someone starting today. Understanding why each piece existed made it easy to decide which ones I could drop once better options showed up.
I still use this setup on train rides, and I would start with Remote Control if I needed only Claude Code access.