Skip to main content

Remote control: steering your AI coding session from your phone

There's a moment when you're deep into an agentic coding session and you have to leave your desk (time to catch my train!). Normally that means the session just sits there, waiting, until you're back at your keyboard. Both Claude Code and GitHub Copilot CLI recently shipped a feature that fixes exactly this: you keep the session running locally, but you can check in, approve tool calls, and keep steering it from your phone or any browser.

Let's look at how each one works.

Claude Code: /remote-control

In Claude Code, you enable this with a slash command inside a running session:

/remote-control

or the short form:

/rc

You can also start a session already remote-enabled:

claude --remote-control

or run a dedicated server process that can host multiple concurrent sessions:

claude remote-control

Whichever way you start it, Claude Code prints a session URL (and lets you press spacebar to show a QR code) that connects to claude.ai/code or the Claude app. From there you get a live view of the terminal: connection status, tool activity, and the ability to send messages back in.

Remark: the architecture is worth understanding. Your local Claude Code process makes an outbound HTTPS connection to the Anthropic API and polls it for instructions — it never opens an inbound port. Your phone doesn't execute anything or touch your files directly; it just renders the conversation and sends prompts. Execution, file access, and MCP servers all stay on your machine.

A few practical details:

  • The local process has to keep running. Close the terminal or quit VS Code, and the session ends.
  • If your machine loses network for more than roughly 10 minutes, the session times out and you'll need to run claude remote-control again.
  • Some commands, like /plugin or /resume, are local-only — they won't work from a remote client.
  • Server mode has a nice trick: claude remote-control --spawn worktree gives each on-demand session its own git worktree, so parallel sessions don't fight over the same files. You switch between them in the Claude app like chat threads, with push notifications when one finishes or needs a decision.

GitHub Copilot CLI: /remote

Copilot CLI has the same idea, just named differently. Inside a running session:

/remote on

Or start the session already remote-enabled:

copilot --remote

Or make it the default for every interactive session by adding this to ~/.copilot/settings.json:

{
  "remoteSessions": true
}

(Override that per session with --no-remote.)

Once enabled, Copilot CLI prints a link to the session on GitHub.com.


Sign in with the same account that started the session and you get a live, steerable view, not just read-only output.

You can also find it without the link: GitHub.com → Copilot icon → "Agent sessions," or the Agents tab of the repo you started the session in.

Remark: don't confuse this with regular session syncing. Copilot CLI sessions sync to your GitHub account by default and show up as view-only on GitHub.com and GitHub Mobile but you can't steer those. Only sessions with remote control explicitly enabled are steerable.

I asked a question on the Github website:

And the agent starts to work on it locally:

On mobile, it's the same experience via GitHub Mobile: tap the Copilot button, find your session under "Agent sessions." For quick access, run /remote in the session to redisplay the details, then press Ctrl+E to toggle a QR code.

One thing Copilot CLI has that I like: /keep-alive. Your laptop going to sleep kills the session just like it would with Claude Code, so you can tell it explicitly to stay awake:

/keep-alive on       # never sleep while the session is active
/keep-alive busy     # only stay awake while Copilot is actively working
/keep-alive 8h       # stay awake for a fixed duration

And if you resume a session later with copilot --continue or copilot --resume, remote control is automatically re-enabled. You don't need to pass --remote again.

Side by side

Both tools solve the same problem the same way: execution stays local, only the conversation travels.

  • Enable inline: /remote-control (or /rc) in Claude Code, /remote on in Copilot CLI.
  • Enable at launch: --remote-control vs. --remote.
  • Always-on default: a settings toggle in Claude Code's /config, or "remoteSessions": true in Copilot CLI's settings.json.
  • Remote client: claude.ai/code or the Claude app for Claude Code; GitHub.com or GitHub Mobile for Copilot CLI.
  • Awake-keeping: Claude Code relies on you keeping a terminal session alive; Copilot CLI gives you a built-in /keep-alive command with fine-grained durations.
  • Parallel sessions: Claude Code's server mode with git worktrees per session; Copilot CLI doesn't need a dedicated server mode since every session syncs to your GitHub account by default.

Which one you reach for probably just comes down to which tool you're already running. If you're bouncing between both like I do, it's worth knowing that both tools have this functionality built-in.

That's it! Two different agent harnesses, same remote control idea.

More information

Labels:

Popular posts from this blog

Podman– Command execution failed with exit code 125

After updating WSL on one of the developer machines, Podman failed to work. When we took a look through Podman Desktop, we noticed that Podman had stopped running and returned the following error message: Error: Command execution failed with exit code 125 Here are the steps we tried to fix the issue: We started by running podman info to get some extra details on what could be wrong: >podman info OS: windows/amd64 provider: wsl version: 5.3.1 Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:2655: connectex: No connection could be made because the target machine actively refused it. That makes sense as the podman VM was not running. Let’s check the VM: >podman machine list NAME         ...
Read more

Cache stampede: when our cache turned against us

While investigating some performance issues, we ran into an ASP.NET Core API that cached a fairly expensive aggregation query for 60 seconds. Under normal load, that was fine: one request rebuilds the cache, everyone else reads from it. Under peak load, dozens of requests would arrive in that same expiry window, all see a cache miss, and all fire the same expensive query in parallel. The database didn't like that. That was the moment when our caching layer stopped helping and started hurting. A burst of requests comes in at the same time, all miss the cache, and all go hammer the database or the downstream API at once. That's a cache stampede . The cache was supposed to protect our backend, and for a few hundred milliseconds it did the opposite. Why this happens IMemoryCache.GetOrCreate (and its async sibling) looks like it protects you, but it doesn't add any locking on its own. Look at the naive version: public async Task<Report> GetReportAsync(string key) ...
Read more

A complex system designed from scratch never works

A few years ago, I worked as an architect on a big mainframe rewrite. I still count it as one of my failures. Not because the technology was wrong, but because I couldn't convince the management team to simplify the approach. Years later, the organization is still struggling to get the new system up and running. I left the project at the time, because I couldn't put my name behind an approach that would take very long and cost a lot of money without a working system to show for it along the way. Gall’s Law That memory keeps coming back to me, because it's a textbook case of Gall's Law playing out in real life. Gall's Law , from John Gall's Systemantics , states it plainly: A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works, and it cannot be patched to make it work. You have to start over with a simple system that works. What does that mean in practice,...
Read more