How to Run AI Coding Agents From Your Phone

Your coding agent runs on your machine. Your phone becomes the control surface — observe, approve, steer, resume.

A local AI coding agent is already the place where the work happens. The interesting question is no longer "how do I install Claude Code?" — it is how do I keep using it after I leave the terminal. The laptop lid closes, the agent keeps running, and you want to check, answer, redirect, or shut it down from the device you actually have on you.

This post is a vendor-neutral map of how that "phone → agent" loop is being built in 2026. It compares the five shapes it currently takes, names what each one is good at, calls out the security trade-offs, and shows where NightMe sits inside one of those shapes.

Why developers want to use coding agents from a phone

The reason is rarely "I want to write code on my phone." The reason is the loop:

1. You start a coding agent on the desktop — Claude Code, Codex, OpenCode, Pi, or any other CLI agent.
2. The agent kicks off a long-running task: a refactor, a test run, a multi-file edit, a migration.
3. You leave the terminal. Coffee. Commute. Meeting. Another machine.
4. The agent keeps working. Every few minutes you want to know: is it still doing the right thing? did it block on me? is the diff big enough to look at now?
5. When it does need you — a permission prompt, a clarifying question, a wrong turn — you want to answer from wherever you are.

The phone shows up because it is the only screen that is always on you. Not because anyone wants to type Rust on a five-inch keyboard.

Your phone is a control surface, not a mobile IDE

There is a recurring framing mistake worth flagging early. "Mobile coding" gets used as a synonym for three different things, and only one of them is what this post is about.

The mental model that holds:

Coding agent runs on your machine
        ↓
You leave the terminal
        ↓
Agent keeps working
        ↓
Phone becomes the control surface
        ↓
Observe / approve / answer / steer / resume

Once you internalise that, the rest of the post is a tour of the five ways the industry has actually built the bottom two arrows.

The main ways to control a coding agent remotely

Each approach below is a real product class in 2026. They are not mutually exclusive — many developers use two of them side by side — but they trade off differently across the dimensions that matter.

SSH + tmux / mosh

The terminal-era default. Open an SSH session to the workstation, attach to a tmux (or mosh, for spotty 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.

• Strengths. Mature, universal, total control. Works against any agent because the agent never knows a phone is involved.
• Weaknesses. Mobile terminals are bad at two things the agent loop needs: reading long tool-call output, and typing anything more than a short command. tmux makes the first slightly better; nothing makes the second better than a real keyboard.

Browser-based remote terminals

A browser-accessible 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 the browser tab.

• Strengths. No app to install. Browser tabs survive across sessions; bookmarks act as "control panel" entries per project. Easy to share a session URL with a teammate for pair-debugging.
• Weaknesses. Same input / output limits as SSH, plus a JavaScript keyboard layer in the way. Auth and exposure are yours to manage — see the security section below.

Vendor-native remote control

Some coding-agent vendors now ship first-party ways to reach a local session from outside the machine. Anthropic's Claude Code Remote Control surfaces the running local session in a browser without moving the model or the source tree off the box. OpenAI's Codex "from anywhere" flow lands at the same destination from a different direction — the local Codex process keeps executing, a phone or browser attaches to it for review, approval, and steering. GitHub Mobile added live notifications and progress tracking for coding-agent sessions, which is the same loop in notification form.

• Strengths. Lowest setup. The vendor has already solved auth, transport, and pairing. Mobile UX is the vendor's primary design target.
• Weaknesses. Single-vendor lock-in for the control surface. If you switch agents, you switch control apps. Some flows require the agent to keep a long-lived outbound connection, which has its own security profile.

Mobile apps and remote coding-agent bridges

Dedicated apps built specifically to control an agent running on a desktop. The category is young but growing; examples include the companion apps vendors ship (or are shipping) for their own agents, plus third-party bridges that sit between an agent's local IPC and a phone-friendly UI. 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, not raw terminal bytes.

• Strengths. Mobile UX is opinionated. Approval prompts are one tap. Status and history are structured, not parsed from a TTY stream.
• Weaknesses. Each app supports some subset of agents and platforms. 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 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.

• Strengths. Zero-install on the phone. The user already knows the chat app's UX, including its offline queue, search history, and per-chat state. Conversations map naturally to projects — one chat per worktree or branch — so context switching is a message, not a tab shuffle.
• Weaknesses. Bridges are agent-agnostic by design; vendor-specific tricks (special permission cards, custom emoji reactions) may not survive the round trip. Latency and media size are bounded by the chat platform, not by you.

What should stay on your machine?

The whole category only makes sense if the heavy stuff stays local. The split is consistent across all five approaches:

The phone never holds the code. It never holds the credentials. It never holds a compiler. What it holds is the conversation and the buttons — which is exactly as much surface area as the agent loop actually needs when you are away from the desk.

What should you be able to do from your phone?

Forget feature lists for a second. The actions that matter, in the order you usually want them:

• See what is happening. Agent name, current task, token usage, last tool call, git state, worktree path. On one screen, without scrolling.
• Answer a question. The agent asks "which JSON shape do you want?" You reply with the answer.
• Approve a permission request. The agent wants to run rm -rf. One tap.
• Steer / redirect. "Skip that approach, use the existing parser instead." The agent queues the new instruction and continues.
• Stop. Cancel the in-flight step. The session parks, ready to resume.
• Resume / continue. Pick the work back up — same session, same context, same machine.
• Review output. A diff. A test summary. A PR link. Inline or attached.

If your remote-control surface only supports a subset of those — say, approve and resume, but not steer — you will end up walking back to the laptop anyway. That is the single most useful test of which approach actually fits your workflow.

Comparing the remote-control approaches

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 cell."

Two non-obvious takeaways from the table:

• "Agent-agnostic" is the column that decides lock-in. If you ever plan to switch agents — and the category is moving fast enough that you should plan to — anything tied to one vendor will need to be re-evaluated at that point.
• "Setup" hides the real cost. Low-setup approaches usually outsource auth, transport, and exposure to a third party, which is a feature for speed and a feature for risk. See below.

Where NightMe fits

NightMe is not a mobile IDE. It is not a cloud coding environment. It does not run your code on someone else's machine.

NightMe is a chat-based control layer: a small daemon on the workstation that bridges the local coding agent to a chat app you already use. Feishu, Lark, Slack, Telegram — the daemon forwards messages to the agent, and forwards the agent's status, tool calls, and prompts back as chat messages. The phone's chat app becomes the control surface described in the table above, without any new app to install.

It is one option in the "Chat-based control" row of the comparison table. If you already live in a chat app at work, that row tends to be the lowest-friction one — but if you would rather not mix work chat and coding-agent output, vendor remote control or a dedicated mobile bridge will fit better.

The choice between chat-based control and the other four shapes is a personal one, not a moral one. The post's job is to make the trade-offs visible, not to rank them.

Which setup is right for you?

A rough matching, not a verdict:

• Terminal-heavy developer, one workstation, deep tmux muscle memory — SSH + tmux. You will out-type a mobile UI anyway.
• Committed to one vendor's coding agent, want the lowest-friction setup — vendor remote control. Re-evaluate the day you consider switching agents.
• Visual, browser-first workflow, occasional mobile use — browser terminal behind a tunnel. Bookmark per project.
• Phone-first, multiple coding agents across multiple projects, already chat-heavy at work — chat-based control. One chat per project keeps context switching cheap.
• Want structured approval cards and per-agent UX on the phone, fine installing a companion app — mobile bridge / app. Pick the one whose agent coverage matches what you actually run.

There is no universally correct row. Most developers who use one of these end up using two: a primary control surface for the daily loop, and a fallback (often SSH) for the cases the primary cannot reach.

Security considerations

This section is the one most "remote coding from your phone" posts skip. Skipping it is how people end up with a coding agent on a workstation that is also exposed to the public internet.

Five things to think through, regardless of which row of the table you pick:

• Exposing a local terminal. A browser-terminal or SSH setup on a routable port is, definitionally, a remote shell anyone with the right credentials can reach. Fail2ban, key-only auth, and a non-standard port reduce noise but do not change the shape of the risk. A VPN or a zero-trust tunnel (Tailscale, Cloudflare Tunnel with Access) is a real boundary; port forwarding + a password is not.
• Broad agent permissions. Coding agents increasingly ask for shell, filesystem, and network access. The phone's job is to be the place you say no quickly. If your control surface cannot surface a permission prompt in a way you can act on in under five seconds, you will rubber-stamp them — and that is where the real damage happens.
• Authentication. Per-device pairing, short-lived tokens, biometric confirmation for sensitive prompts — these exist in 2026 and are worth turning on. Static long-lived API keys on a phone 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.
• Dangerous permissions deserve a separate gate. "Run any shell command" and "send a Slack message to anyone" are not the same risk class. If your control surface treats them as one tap each, treat that as a feature gap and act accordingly.

None of this is unique to coding-agent control. It is the same shape as remote server administration. The reason it is worth restating here is that the convenience of phone-based control — a one-tap approval while you are in a meeting — is also what makes it dangerous when misconfigured.

The bigger shift: coding agents are becoming persistent collaborators

The category this post is mapping is not really about phones. It is about a deeper change: coding agents are no longer single-shot tools. 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.

That is the real reason the rows in the comparison table exist: they are five different answers to the same question — where should the human live in an agent-driven workflow? Each row picks a different primary surface (the terminal, the browser, the vendor app, the bridge app, the chat app) and leaves the others as fallbacks.

Phones did not invent the shift. Phones are just where the shift shows up first, because they are the device you always have with you when the question becomes interesting.

What's next

• Run your first agent session — the NightMe-specific walkthrough of the loop this post describes in the abstract.
• Run agents in parallel — one chat per project, multiple agents in flight at once.
• Stop babysitting your coding agents — the category framing behind NightMe's design.

Related reading — internal pages covering adjacent surfaces:

• Remote / continue coding agents — internal page planned; link will be added when published.
• Coding agents from your phone / chat — internal page planned; link will be added when published.