How to Keep Using Claude Code After You Leave the Terminal

Learn how to keep Claude Code running on your machine and control it remotely from your phone — SSH, vendor remote, chat-based, and beyond.

How do you keep using Claude Code after you leave the terminal? That is the question behind almost every search for "Claude Code from phone", "Claude Code remote control", and "Claude Code on your phone" — and it is a question that does not actually have a Claude-Code-specific answer. Claude Code is the most-searched instance of a broader problem: how do you keep controlling a local coding agent after you are no longer at the machine where it is running? This article uses Claude Code as the entry point into that broader question, walks through the architectures that solve it, and explains where an agent-agnostic control layer fits in.

The remote-coding-agent workflow

A coding agent is local-first by design. The model runs in a process on your machine. The source tree it edits lives on your filesystem. The tools it calls — compilers, test runners, package managers — are the ones installed on your laptop. MCP servers, environment variables, credentials, ~/.claude/settings.json: all of it stays with the host.

That is also what makes the agent useful. It is operating on the real code, in the real project, with the real permissions. The cost is that the agent is bound to wherever the machine is.

The moment you leave the desk, the workflow breaks open:

• You close the laptop lid for a meeting.
• You board a train or a plane.
• You walk away from the desk for the day.

The agent keeps running. A long refactor, a multi-file edit, a test suite, a migration — none of these pause because you did. Every few minutes the agent makes progress. Every so often it stops to ask you something.

The interruption loop is where the remote-control question actually lives. Three classes of interruption dominate, and each one has to be reachable from wherever you are:

• A question it cannot answer alone. "Which JSON shape do you want?" "Should I run the tests in serial or parallel?" "What is the deploy environment for this branch?" You want to answer without walking back.
• A permission prompt. A shell command, a file write, a network call. You want to glance at the request and tap yes or no.
• A wrong turn. The agent is editing the wrong file, calling the wrong tool, taking the wrong approach. You want to steer before twenty more tool calls stack on top of the bad decision.

What "remote control" actually has to cover, in the order you usually want it: observe progress, answer questions, approve permissions, steer direction, stop in flight, resume later, review the diff. If a control surface only covers a subset — approve and resume but not steer, for example — you end up walking back to the laptop anyway. That is the single most useful test of whether a remote approach actually fits your workflow.

This is also why "mobile coding" is the wrong frame. Nobody wants to type Rust on a five-inch keyboard. The phone shows up because it is the only screen that is always on you. The agent does not move to the phone; the phone becomes a window into the agent that is still on the laptop.

Claude Code is the canonical example today because the search volume concentrates here, the agent loop is mature, and the surface area for "what could go wrong if I just SSH in" is large enough that people actively look for alternatives. But the same workflow applies to any local coding agent — Codex, OpenCode, Pi, and the next one. The rest of this article is about the architectures for solving it, with Claude Code folded in as the most-searched instance rather than as the only one that matters.

Five architectures for solving the remote-coding-agent workflow

Five shapes have converged in 2026 for keeping a local coding agent reachable after the laptop closes. Each one solves the workflow differently. None of them is universally best — they trade off across the dimensions that matter.

SSH + tmux / mosh

The terminal-era default. Open an SSH session to the workstation, attach to the tmux (or mosh, for spotty mobile connections) session the agent is running in, and drive it the same way you would from a desk. The phone becomes a thin terminal client — Termius, Blink, or any of a dozen iOS / Android SSH apps.

It works against any agent because the agent never knows a phone is involved. The agent's tool calls still scroll past as raw text, and any prompt you would see on the terminal still shows up on the terminal — just on a five-inch screen instead of a fifteen-inch one. tmux makes long output slightly easier to scroll through; nothing makes typing a long prompt easier than a real keyboard.

Browser-accessible terminal

A browser shell on the workstation — Tailscale's web SSH, a self-hosted ttyd / wetty / GoTTY, a Cloudflare Tunnel in front of an existing SSH daemon. The phone opens a URL in Safari or Chrome and gets a full terminal inside a browser tab. No app to install. Browser tabs survive across sessions; bookmarks act as "control panel" entries per project. Same input / output limits as SSH, plus a JavaScript keyboard layer between you and the shell. Auth and exposure are yours to manage.

Vendor-native remote control

Several coding-agent vendors now ship first-party ways to reach a local session from outside the machine. Anthropic's Claude Code ships Remote Control, which lets a phone or browser attach to a running local session over an outbound HTTPS connection to the Anthropic API: the local Claude Code process keeps running, files / tools / MCP / credentials stay on the host, and the phone becomes a structured window into that session with proper tool-call cards, diff panes, and permission prompts. The current Anthropic implementation requires a Pro / Max / Team / Enterprise claude.ai subscription, talks only to api.anthropic.com directly (Bedrock / Vertex / Foundry / custom ANTHROPIC_BASE_URL are not supported), keeps the local process running to keep the session alive, and exposes only a subset of /commands from the phone. OpenAI's Codex "from anywhere" flow lands at the same destination from a different direction, and GitHub Mobile added live notifications and progress tracking for coding-agent sessions as the same loop in notification form. The vendor-native shape gives the lowest setup, but it ties the control surface to one vendor — switch agents, switch control apps.

Mobile apps and dedicated bridges

Dedicated apps built specifically to control an agent running on a desktop. The category is young but growing. The defining trait is that the app knows about the agent loop, not just the shell — it surfaces tool calls, diffs, token usage, and approval prompts as first-class objects rather than parsing them out of a TTY stream. Mobile UX is opinionated; approval prompts are one tap. The cost is that each app supports some subset of agents and platforms, and setup usually means installing two things — the bridge on the box, the app on the phone — and keeping them paired.

Chat-based control

The newest shape. The phone's chat app — Feishu, Lark, Slack, Telegram, Discord, iMessage, WhatsApp — becomes the control surface. A small bridge on the workstation forwards messages to and from the local coding agent; the chat app's existing notification, reply, and reaction UX carries the agent loop without any new app to install on the phone. Conversations map naturally to projects — one chat per worktree or branch — so context switching is a message, not a tab shuffle. The cost is that bridges are agent-agnostic by design, so vendor-specific tricks may not survive the round trip, and media size / latency are bounded by the chat platform.

For a vendor-neutral deep-dive across these five shapes — full trade-off table, security trade-offs in detail, and the reasoning behind the categorization — see How to run AI coding agents from your phone. The rest of this article zooms back in on Claude Code and the agent-agnostic insight.

An agent-agnostic control layer

A coding agent is replaceable in a way that the workflow is not. You might use Claude Code today, Codex next quarter, Pi or OpenCode for a specific job the week after, and a brand-new agent the year after that. If the remote-control surface is locked to one vendor, every agent switch is also a control-app switch — the workflow you built around Claude Code Remote Control does not carry over, the phone app you installed does not carry over, and the muscle memory does not carry over.

The insight is that the workflow should survive when the underlying coding agent changes. The shape that does this best is the chat-based control layer: it does not know or care which CLI agent is loaded into the bridge, only that messages go in and structured tool-call / status events come out. Switching agents becomes a /use claude / /use codex / /use pi command inside the same chat, not a new phone app.

NightMe is one implementation of this shape. It is not Claude Code Remote Control, not a mobile IDE, not a cloud coding environment. It is a small daemon on the workstation that bridges the local coding agent to a chat app you already use, with the agent process running locally so files / tools / MCP / credentials stay on the host and worktree isolation keeps parallel agents from clobbering each other. To see the loop in action — three commands and you have a Claude Code session you can steer from your phone — see Run your first agent session. To see what running multiple agents in parallel actually looks like in practice, see Run agents in parallel. For the /gtw fix / /gtw close workflow that turns a chat into a one-shot PR, see /gtw fix one-shot fixes.

What's next

• Run AI coding agents from your phone — vendor-neutral five-architecture deep-dive, full trade-off table, security section.
• Run your first agent session — three commands from nightme start to a Claude Code session you can steer from your phone.
• Run agents in parallel — one chat per project, multiple agents in flight, scoped CWDs.
• /gtw fix one-shot fixes — turn a chat into a one-shot PR with /gtw fix and /gtw close.
• Coding agents without babysitting — the category framing behind NightMe's design.

Remote / Continue Coding Agents — internal page planned; link will be added when published.

Last updated: 2026-09-17 — verified against code.claude.com/docs/en/remote-control the same day. Anthropic ships Remote Control changes on a fast cadence; verify before relying on any specific cell in this article.