How to Control AI Coding Agents From Anywhere

Local coding agents keep working after you leave the desk. Remote control is the architecture, the persistence, and the human-agent loop — not just the connection.

A coding agent is running on a home machine, a Mac mini, a devbox, or a remote development environment. It is mid-refactor, mid-test-suite, mid-migration. The laptop is closed. The developer is somewhere else. The question behind every search for "control AI coding agents from anywhere", "remote coding agents", and "coding agents from anywhere" is not "which tool do I install" — it is what does remote control of a local coding agent actually require, and how do the different architectures satisfy those requirements?

This article is the architecture-first answer. It is deliberately not a "five ways to remote into your box" listicle. The five-architecture deep-dive lives in How to run AI coding agents from your phone; the Claude-specific walkthrough lives in Run Claude Code from your phone. What follows is the upstream mental model: what "remote coding" means, what has to survive when you leave, how the human-agent loop is supposed to keep working, and which architectures actually carry that loop versus which only give you a shell.

The problem: your agent keeps working after you leave

The shape of the problem is the same whether you left the desk for ten minutes or ten hours:

• The agent is running on a workstation you are no longer sitting at.
• The agent is making progress, asking questions, requesting permission, or making a wrong turn.
• The terminal is no longer the right control surface, because the terminal is closed.

This is not a phone problem and it is not a vendor problem. It is a workflow problem. The developer is supervising a process that is no longer in front of them, and the supervision has to survive the absence.

The interruption loop is what makes the absence interesting. Three classes of interruption dominate, and each one has to be reachable from wherever the developer is:

• A question the agent cannot answer alone. "Which JSON shape do you want?" "Should the migration run in serial or parallel?" "What is the deploy environment for this branch?"
• A permission prompt. A shell command, a file write, a network call. The agent pauses until somebody says yes or no.
• A wrong turn. The agent is editing the wrong file, calling the wrong tool, taking the wrong approach. The wrong turn is cheaper to fix the moment it happens than twenty tool calls later.

If the developer's control surface cannot reach any of those three — if it can show progress but cannot answer, or can answer but cannot redirect — the developer will end up walking back to the laptop. That single test is more useful than any feature list: does the remote surface let the human-agent loop actually close, or does it just let you watch?

Remote coding is not the same as cloud coding

Three architectures get conflated, and only one of them is what this article is about.

Local agent + remote control is the subject. The key property is that the agent, the source tree, the local tools, the MCP servers, and the credentials all stay on the host, and the human enters from somewhere else. That property is what lets the workflow survive switching vendors, switching machines, and switching between desk and away.

Cloud-hosted coding agents are a different product class. They solve a real problem — no local install, no local hardware — but they give up the property that the source tree and the credentials live where the developer can audit them. They are not what the search intent behind "from anywhere" is pointing at, and they are not what this article is comparing.

Remote shell / terminal access is the lowest layer. It is one of the architectures the next sections discuss, but it is not the architecture. SSH alone is not a remote-coding-agent workflow; it is the ability to reach a shell.

What must survive when you leave the machine?

The difference between "I SSHed in and started a new agent" and "I returned to the same work" is the difference between remote access and a remote coding workflow. Remote access answers can I reach the machine? A remote coding workflow answers can I return to the same work?

The state that has to survive the absence:

• Running process. The agent process must keep running while the human is gone. Closing it means losing whatever it had in flight.
• Conversation / session history. The accumulated context — what was tried, what was rejected, what is currently true about the task — is the agent's working memory. Restarting from scratch throws that away.
• Project / CWD. The agent must still be editing the right project, in the right branch, with the right working directory. A new shell that drops you into $HOME is not the same session.
• Local tools and MCP. Compilers, test runners, package managers, MCP servers — the agent's tool surface must still be the developer's actual tool surface, not whatever happens to be installed in a fresh container.
• Permission state. What the agent is allowed to do without asking, and what it has to ask about, must be the same after the human returns.
• Current task state. Where the agent is in the task, what it has already produced, what is left to do.
• Output / progress visibility. The human has to be able to look at where the agent is, without scrolling a raw TTY stream on a five-inch screen.
• Ability to reconnect to the same session. When the human returns, they have to land back in the same session — same conversation, same context, same machine — not a parallel one.

"Open a new terminal and start a new agent" fails the list above on almost every row. A persistent remote workflow requires that all of them survive. The architectures below are graded against this list, not against "did I get a shell".

A remote coding-agent workflow has four jobs

The cleanest way to organise the surface area is by the four jobs the human-agent loop has to keep doing while the human is away. They are jobs, not features, and they are ordered by the order the developer usually wants them in:

OBSERVE
  What is happening?
      ↓
RESPOND
  Does the agent need an answer or permission?
      ↓
DIRECT
  Should I stop, steer, or change context?
      ↓
CONTINUE
  What should happen next?

• Observe. Status that answers: which session, which project, which agent, current task, last tool call, what it is waiting on. Glanceable. One screen. No TTY scrollback.
• Respond. The surface has to let the human answer a clarifying question and approve (or reject) a permission prompt. Both without leaving the surface.
• Direct. Stop the agent mid-flight, steer it onto a different approach, change context, or change the brief. The agent queue accepts the redirect; the human does not have to be at the terminal to issue it.
• Continue. The same session, the same context, the same machine — picked back up hours or days later, with the conversation intact.

Remote control is not "remote viewing of a terminal". It is keeping this loop alive when the developer's body is not at the desk. Architectures that cover only part of the loop — only observe and continue, say — will look fine until the first permission prompt, and then the developer walks back to the laptop anyway.

Different remote architectures solve different parts of the problem

There is no single correct architecture. There are several, each of which covers a different subset of the four jobs and a different subset of the state that has to survive. Below they are introduced as architecture examples, not as five parallel how-to guides — the mobile-specific setup details live in How to run AI coding agents from your phone, and the Claude-Code-specific setup lives in Run Claude Code from your phone.

The architectures in scope:

• SSH + tmux / mosh — a shell session that survives the absence, with the agent running inside it.
• VPN / private remote access — Tailscale, WireGuard, ZeroTier, or a corporate VPN, on top of whatever the workstation already exposes.
• Browser-based terminals / remote sessions — a web shell in front of an existing SSH daemon or a self-hosted ttyd / wetty / GoTTY, optionally behind a tunnel.
• Vendor-native remote control — the local coding-agent vendor ships a first-party way to attach to a running local session (Anthropic's Claude Code Remote Control, OpenAI's Codex "from anywhere", GitHub Mobile live notifications).
• Mobile apps and dedicated bridges — companion apps designed for the agent loop specifically, not for shells generally.
• Chat-based control — the existing chat app (Feishu, Lark, Slack, Telegram, Discord, iMessage, WhatsApp) becomes the control surface, with a small bridge on the workstation forwarding messages to and from the agent.

These architectures are not mutually exclusive. Most developers who use one of them end up using two: a primary control surface for the daily loop, and a fallback (often SSH) for the cases the primary cannot reach. What matters is which parts of the four-job loop each one covers, and what trade-offs they take to cover them.

Comparing the architectures across the dimensions that matter

Capabilities below are based on what is verifiable in vendor docs and shipped products as of late 2026. Vendor features in this row change quickly — verify against current docs before relying on a specific cell.

Two non-obvious takeaways from the table:

• "Agent lock-in" is the column that decides the cost of switching vendors. If you ever plan to switch agents — and the category is moving fast enough that you should plan to — anything tied to one vendor's control surface will need to be re-evaluated at that point.
• "Session persistence" is the column that decides whether the architecture is actually a workflow or just a connection. Architecture rows where persistence "depends" can be made persistent with effort (tmux, a long-lived container, a vendor's "keep alive" toggle) — but the cost is on you, not on the architecture.

The point of presenting these as rows and not as five parallel how-to sections is that the architecture is a trade-off across all seven columns at once, not a pick-and-mix. A vendor-native surface gives you the lowest setup and the highest intervention coverage, in exchange for the highest lock-in. SSH + tmux gives you the lowest lock-in and the lowest phone usability, in exchange for universal coverage of any agent. The right choice depends on which trade-off the developer wants to make.

Why persistent sessions matter more than remote access alone

A shell you can reach from anywhere is not the same thing as a remote coding workflow. The distinguishing property is persistence: when the developer comes back, do they land in the same session, with the same context, on the same machine?

What persistence buys:

• Conversation history. The accumulated turns, tool calls, rejections, and follow-ups that constitute the agent's working memory.
• Project / CWD. The right branch, the right worktree, the right working directory — without having to navigate back.
• Local process. The agent process is still alive, mid-task, and continues from where it left off.
• Permission state. What the agent is and is not allowed to do is unchanged.
• Returning later. Pick the session back up hours or days later, with the conversation intact and no re-prompting required.
• Avoiding restart / context loss. Restarting an agent re-establishes a connection and re-summarises everything it already knows, which is itself a slow process with imperfect fidelity.

A "remote access" architecture that loses persistence on disconnect — that spins up a fresh shell, a fresh agent, a fresh context — is a remote-access architecture, not a remote coding workflow. The next sections on security and on where NightMe fits both turn on this distinction. Persistent sessions also point upstream at the category framing — the more the developer's sessions are persistent, supervised, and interruptible, the closer the workflow gets to the category described in Coding agents without babysitting.

Security is part of the architecture

Security is not a checklist that sits beside the architecture choice; it is a property of the architecture. Different architectures put the trust boundary in different places, and the right question is not "is it secure" but "where does the trust boundary sit, and what does it cost to keep it there".

Considerations that are common to all rows:

• Public SSH exposure. A routable SSH port is, definitionally, a remote shell anyone with the right credentials can reach. Fail2ban, key-only auth, and a non-standard port reduce noise; a VPN or zero-trust tunnel (Tailscale, Cloudflare Tunnel with Access) is a real boundary.
• Relay services. Any architecture that proxies control traffic through a third party is outsourcing part of the trust boundary to that third party. Read the relay's threat model before relying on it for sensitive work.
• Authentication. Per-device pairing, short-lived tokens, biometric confirmation for sensitive prompts are all worth turning on. Static long-lived API keys on a device that may be lost or stolen are the worst combination.
• Trusted devices. Decide which phones, browsers, or chat accounts are allowed to talk to the agent. A separate, narrow "agent control" identity per device beats reusing a personal account with full access.
• Agent permissions. The control surface is the place the developer says no quickly. If a permission prompt takes five seconds to reach the developer, the developer rubber-stamps it — and that is where the real damage happens.
• Secrets and credentials. The workstation's secrets do not move to the control surface. If an architecture requires them to, the architecture has a problem the developer has to manage.
• Compromise of the control surface. If the phone is stolen, the chat account is taken over, or the browser session is hijacked, what can the attacker do to the workstation? The answer depends on which row of the table above is in play.

Security implementations in this space change quickly. Verify against the current first-party documentation before relying on a specific configuration.

When a remote coding-agent workflow becomes useful

The architectures above solve for a workflow that already exists. They become useful in concrete situations, not in the abstract:

• Long-running tasks. Refactors, migrations, multi-file edits, and test suites that exceed the developer's patience to watch from a desk.
• Large test or build jobs. A CI-style run on the workstation, where the developer wants to peek at progress without sitting in front of it.
• Overnight work. Starting an agent before bed, returning to it in the morning on the same session.
• Multiple projects or sessions. Two or more agents on disjoint worktrees, each on its own branch — the workflow that makes the "parallel agents" pattern in Running multiple AI coding agents in parallel workable in practice.
• Developer away from desk. Coffee, commute, meeting, travel, picking up a child from school — any of the moments the developer's body is not at the terminal.
• Home server, Mac mini, or devbox. The agent runs on hardware the developer does not normally sit at, and the developer reaches it from whatever device is at hand.
• Returning later. Coming back to a session hours or days after it was started, with the conversation intact.

None of these is unique to one architecture. The pattern is the same: the developer is supervising a long-running agent process, and the supervision needs to survive their absence. The architecture choice is which row of the comparison table above best fits the developer's tolerance for setup, lock-in, and security work.

Where NightMe fits

NightMe is a chat-native control layer for local coding agents. It is one option in the "Chat control" row of the comparison table, not a category of its own.

What that means in practice:

• Code stays on the user's machine. The source tree, the build tools, the MCP servers, the credentials — none of it leaves the workstation. The chat app sees only the conversation the developer would have had with the agent at the terminal.
• The agent stays in the user's existing local environment. The same Claude Code, Codex, OpenCode, or Pi process the developer would have started by hand. NightMe is a bridge on top of the local CLI, not a replacement for it.
• The same session can be controlled remotely. When the developer leaves the desk, the conversation keeps flowing through the same chat thread. Returning hours later means opening the same chat, not starting a new session.
• Supported agents share the same conversation-centred workflow. /use claude, /use codex, /use pi — switch the underlying agent inside the same chat, not a different phone app per vendor.
• The control surface is a chat the developer already uses. Feishu, Lark, Slack, Telegram — the developer does not install a new mobile app to talk to their agent.

This is one architecture row, not a recommendation against the others. For developers who already live in a chat app at work, chat control tends to be the lowest-friction row of the table. For developers who would rather keep work chat and coding-agent output separated, vendor-native remote control or a dedicated mobile bridge will fit better. The architecture comparison table above is the place to make the trade-off, not this section.

The direction of coding-agent workflows

The category this article is mapping is moving in one direction. Coding agents are no longer single-shot tools that respond to a prompt and exit. They run for hours, switch context across files, ask mid-flight questions, and need to be steered rather than re-prompted. Once that is true, the terminal at the desk stops being the right control surface, and any device with a text input and a notification badge becomes a candidate.

The direction is visible in the first-party product evidence:

• Anthropic's Claude Code ships Remote Control as a first-class way to attach to a running local session from outside the host machine, with the source tree, tools, MCP, and credentials staying on the host.
• OpenAI's Codex publishes a "from anywhere" flow that lands at the same destination from a different direction: the local Codex process keeps executing, and a phone or browser attaches to it for review, approval, and steering.
• GitHub Mobile shipped live notifications and progress tracking for coding-agent sessions in 2026 — the same human-agent loop, surfaced as a notification.
• Community discussion on Reddit, Hacker News, and GitHub around remote agents, persistent coding sessions, and phone control has moved from "is this possible" to "which architecture is right for my workflow".

The point is not "agents are getting better". The point is that the loop is moving from interactive CLI tool to persistent worker that humans supervise intermittently. Once the loop is intermittent, the control surface has to be intermittent too — and that is the whole point of the architectures in the comparison table above.

The category framing behind this — what it means to live with always-on coding agents, how to keep them useful without letting them consume the working day — lives in Coding agents without babysitting. The interruption layer that any of these architectures has to support is the subject of When your coding agent needs you — internal page planned; link will be added when published. The mobile-specific five-architecture deep-dive lives in How to run AI coding agents from your phone, and the Claude-Code-specific setup lives in Run Claude Code from your phone.

What's next

• Why AI coding agents still need human intervention — the upstream framing: why every autonomous agent still pauses for a human, and what changes between polling for the pause and being told the pause has happened.
• How to run AI coding agents from your phone — vendor-neutral five-architecture deep-dive, full trade-off table, security section, comparison row-by-row.
• Run Claude Code from your phone — Claude-Code-specific walkthrough: what changes when the agent in the loop is Claude Code.
• Running multiple AI coding agents in parallel — what becomes hard once you have more than one agent in flight; isolation, attention, intervention.
• Coding agents without babysitting — the category framing behind the persistent, supervised coding-agent workflow.

Remote / continue coding agents — internal page planned; link will be added when published.