How to work with coding agents from your phone

You can ask a coding agent to fix a bug from your phone, put the phone away, and come back to a change ready for review.

The code usually runs somewhere else. Your phone gives you a way to describe the task, answer questions, and inspect the result. That makes it useful even if you have no interest in typing code on a tiny keyboard.

There are now quite a few ways to do this. Some agents have their own mobile apps. Others work through a browser or a messaging app such as Telegram. You can hand work to a cloud environment, reach an agent on your computer, or build an app through a phone interface.

Let’s look at what each option gives you, and how I would choose between them.

First, decide where the work runs

A mobile app doesn’t tell you where the agent executes commands.

That distinction matters when your laptop sleeps or your phone loses reception.

The model can run somewhere else in every arrangement. Running an agent program on Android doesn’t mean its language model also runs on Android. It may still call a hosted API.

If you want to close your laptop and leave home, choose a cloud agent or prepare another machine that stays online. Remote control of a sleeping laptop won’t help until it wakes up.

A quick comparison of the tools

Here are the main options covered below. Some are complete coding products. Others give an existing agent a mobile interface.

Feature availability changes, especially around mobile rollouts. The official links in each section are where to check your platform and account requirements.

OpenAI Codex

Codex on mobile lets you start tasks, follow progress, approve actions, and review diffs from the ChatGPT mobile app.

You can choose a cloud environment or a connected computer. The connected-computer route gives the agent access to that host’s projects and configured tools.

To set it up, open the ChatGPT desktop app on your Mac or Windows PC. Go to Settings → Connections → Control this Mac or PC, start setup, and scan the QR code with your phone. Use the same account and workspace on both devices.

On iOS, open Codex. Some app versions still call the area Remote. OpenAI’s remote connections guide also documents Android access, with availability depending on rollout.

I would choose the connected computer when a task needs my existing local setup. A cloud task is useful when I want a separate development environment that can work while my computer is off.

The host must stay awake and online for local work. Pairing your phone doesn’t move that work into the cloud.

Claude Code

Anthropic’s Claude Code mobile guide covers the Claude app on iOS and Android. Open its Code tab to reach coding sessions.

Cloud sessions

Claude Code cloud sessions run on cloud infrastructure. With GitHub connected, select a repository and branch, then describe the task. You can leave the phone and return later to guide the same session.

This is useful for work that can run from the repository and its configured environment.

Remote Control

Remote Control reaches a Claude Code session on your own machine. Start it from the project directory:

claude remote-control

For a session already running, use /remote-control inside Claude Code. Connect through the session link, QR code, or the session list in the app.

The local filesystem and configured tools stay available because the agent remains on your computer. Keep that machine on and the process running.

Cloud sessions and Remote Control require an eligible Claude subscription and account configuration. An Anthropic API key alone doesn’t provide these mobile connections.

Dispatch

The same mobile guide also describes Dispatch, which lets you message a task to the Claude Desktop app. It can start a Code session to handle the work. Dispatch requires Pro or Max, and the desktop computer still needs to be available.

I would start with Remote Control for an existing terminal workflow. Dispatch is another route when I want to send the desktop app a task from the phone.

Google Jules

Jules is Google’s asynchronous coding agent. It connects to GitHub and runs tasks in a VM where it clones the repository, installs dependencies, and changes files.

Its browser interface gives you a way to submit work without maintaining your own remote machine.

Sign in with Google, connect GitHub, select a repository and branch, and describe the change. Jules generates a plan you can review before it edits code. You can leave while it works and return when it needs feedback or finishes.

A useful first task would be adding a missing test or fixing a bug with clear reproduction steps. Review its plan before approving an implementation that touches several parts of your application.

I would use Jules for repository tasks that can be prepared in its VM. Work depending on an app installed only on my Mac needs a different arrangement.

Google Antigravity

Antigravity Remote Control lets you reach its desktop app and CLI sessions from a phone browser. The agent keeps using the files and tools on the host computer.

In the desktop app, open Settings → Application and turn on Enable Remote Control. Give the device a recognizable name. Open the Remote Control dashboard linked from the documentation on your phone, sign in with the same Google account, and select that machine.

You can start tasks, follow conversations, review implementation plans, and inspect artifacts. Installing the web app on your home screen also enables its mobile push-notification workflow.

For a CLI session already running, enter:

/remote-control

Open the link it prints on your phone. This connection lasts while that interactive CLI process runs. /remote-control off disconnects remote access while leaving the local session running.

For a machine you want to keep available without an open terminal, Antigravity also documents a background service:

agy remote-control start

The service and an interactive session have different lifetimes, but both need an awake, connected host. Account or organization policy can also restrict Remote Control.

I would use this when I already have an Antigravity task running locally and need to step away. It preserves that development environment, whereas Jules prepares its own cloud VM.

Cursor

Cursor’s native iOS app supports both cloud agents and Remote Control of agents running on your computer.

From the app you can start work, send follow-up instructions, and review changes. Cursor also provides mobile features such as voice input, notifications, and image markup for visual feedback.

Cloud agents get their own development VMs. They can return artifacts such as screenshots, videos, and logs to help you review what happened.

That is useful for an interface change. I would ask for a walkthrough of the changed flow, then inspect the diff and test results alongside it.

Remote Control is useful when the task needs your desktop environment. Keep the computer awake while connected.

There is also a web interface, covered by Cursor’s web and mobile documentation. Check that route if the native app isn’t available for your phone.

Grok Bot with Cursor

Grok Bot’s mobile app is available on iPhone and Android. It connects to the same Bots, conversations, and persistent cloud computer as the desktop app. Cloud work continues after you close the app or your laptop.

You can use it to coordinate a coding task with Cursor. The Bot gathers context, turns it into an implementation request, and hands the code change to a Cursor Cloud Agent. Cursor’s explanation of the two products describes this handoff.

This is useful when the task begins with information outside the repository. For example, you could send the Bot a screenshot of a broken page and a customer report. Ask it to reproduce the problem and prepare a focused task for Cursor.

To get started:

1. Install Grok Bot from the App Store or Google Play, using the links in its mobile guide.
2. Sign in with the same Cursor account you use on desktop. Check the current access requirements for your subscription; some accounts use a linked Grok subscription.
3. Open an existing Bot or create one. Prepare Cursor’s repository access and cloud environment before assigning implementation work.
4. Name the repository, branch, and expected result in your message. Ask the Bot to confirm that it can hand the task to Cursor before starting.
5. Enable notifications if you want to know when it needs an answer or has a result to review.

For example, I would send a small task like this:

Use the screenshot attached to reproduce the broken reading-list
filter in staging. Confirm which repository and branch you will use.

Explain the cause and proposed fix first. After I approve the plan,
start a Cursor Cloud Agent to implement only that fix and add a
regression test.

Bring back the pull request link, changed files, test results,
and a screenshot of the working filter. Do not merge or deploy.

From the phone you can follow the conversation, answer questions, approve steps, and inspect the Bot’s computer. If a sign-in needs your help, take over the shared screen, finish that step, then hand control back.

The Bot’s cloud computer is separate from your laptop. Unsaved files or services available only on your Mac won’t automatically be available to it. Some setup also stays on desktop, including editing routine schedules and teaching browser workflows by demonstration.

I would use this arrangement when I want the Bot to investigate a report and coordinate the follow-up. For a code change I can already describe precisely, I would send it straight to Cursor through the mobile or web interface.

My Grok Bot guide covers its shared computer, connected apps, skills, and approval settings in more depth.

Amp

Amp supports mobile web access at ampcode.com. Sign in with your existing account to follow threads and send instructions from your phone.

Its native apps provide another route. The iPhone and iPad app is distributed as a TestFlight beta. Android is an experimental APK download, with manual updates and no notifications yet. Check the linked requirements before choosing the native client.

Amp calls its hosted agent environments orbs. A task in an orb runs remotely, so you can continue the thread from your phone without keeping your laptop open.

Alternatively, prepare a runner on your own computer or server. From the project directory on that host, run:

amp --no-tui

It waits for remotely created threads in that directory. On ampcode.com, start a thread and choose the connected runner as its execution location. Keep the runner process and host available while it works.

I would use an orb for a task that can work in a hosted environment. A runner is useful when the task depends on my existing files or local tools. Before sending the first prompt from the phone, check which location the thread will use.

Cline Cloud Agents

Cline Cloud Agents work in a mobile browser. Each task runs in its own cloud sandbox, and work continues when you close the tab.

Open app.cline.bot, sign in, and connect GitHub. Choose which repositories Cline may access. In the Agents tab, pick a repository and branch, choose a model, and describe the task.

From your phone, you can read progress, answer questions, and send follow-up instructions. Cline commits and pushes its work to a separate branch. Ask it to open a pull request when the change is ready for review.

For a first task, I would ask for a regression test around a bug I can reproduce. That gives me a small diff and a clear way to check the result through GitHub.

Cloud sessions have an important limitation: the documentation currently says they don’t load your Cline rules, skills, MCP servers, or connectors. Include the instructions the task needs, and check whether its dependencies are available in the sandbox.

This is a separate execution environment from Cline in your editor. A local integration that works on your laptop won’t automatically be available to the cloud agent.

GitHub Copilot

GitHub has two mobile workflows worth separating.

Copilot cloud agent

You can start a Copilot cloud session from GitHub Mobile. Select a repository, enter the task, and optionally choose the base branch. Ask it to open a pull request if that is the result you want.

You can also assign an existing issue to Copilot from the app. This makes a well-written issue useful as the task description.

For example, an issue can include the failing behavior, the expected result, and a reproduction. You can delegate it while away from your desk, then inspect the resulting changes through GitHub.

Cloud agent access requires a paid Copilot plan and can be restricted by repository or organization settings.

Remote control of Copilot CLI

GitHub also documents remote control of Copilot CLI.

Inside an interactive CLI session, enter:

/remote on

Then open that session under Agent sessions in GitHub Mobile. Use the same GitHub account that started it.

The CLI keeps running on its original machine. The /keep-alive command can prevent that machine from sleeping while you work remotely.

I would use the cloud agent for a self-contained issue. Remote CLI control fits a task already underway in my development environment.

Replit

Replit has mobile apps for iOS and Android. You can create, share, and publish web apps from the phone.

This is a useful option when you want the development environment and deployment workflow in the same product. You describe a small app, inspect the preview, and continue asking for changes.

For example, start with a reading list that accepts a title and URL. Once that works, add editing and deletion. Try each flow in the preview before requesting more features.

There is an important distinction in Replit’s mobile documentation. Its phone app is for building websites and web apps. For Replit’s native iOS app-building and App Store submission workflow, it directs you to the web product.

Choose based on what you want to build and the interface you want to build it from. Those are separate questions.

Lovable

Lovable’s mobile apps are available on iOS and Android. They share your account, projects, and credits with the web product.

You can start a project, continue its chat, dictate a prompt, attach a photo, and switch between chat and preview. Push notifications can bring you back when a build needs attention.

I would use the photo input for a sketch of a screen, then explain what its buttons should do. A drawing helps with layout, but the behavior still needs a written description.

Some setup stays on the web. Create your Lovable account on the website first. OAuth integrations also need to be connected through lovable.dev before you use them in the app. Detailed code review and the preview annotation toolbar also need a wider screen.

That makes the phone useful for continuing a prepared project. Check the documented limits before expecting to configure every integration from inside the app.

Bolt

Bolt supports mobile browsers. You can start projects, chat, inspect previews, and publish from a phone or tablet. You can also add it to your home screen.

The mobile workflow has specific limits. Code view, visual edits, and the database interface require desktop. You can restore an earlier version from mobile, but previewing that historical version before restoring requires desktop.

I would use Bolt from a phone for prompt-driven changes that I can verify in the running app. If I need to inspect a database or edit source directly, I would return to the desktop interface.

Bolt can also create mobile applications through Expo. That describes the application being built. Mobile browser support describes where you operate Bolt. Check both when planning a phone-only project.

v0

Vercel’s v0 has a native iOS app. It lets you start chats, continue existing conversations, preview generated interfaces, and work with GitHub-connected projects.

You can manage environment variables and select MCP servers for chats. Adding or configuring new MCP server presets requires desktop.

I would use it to iterate on a web interface while looking at the result on an actual phone. For example, ask for a signup form, try it with the keyboard open, and check whether the submit button remains reachable.

That kind of feedback is more useful than asking the agent to “make it mobile friendly.” Describe the behavior you observed and the screen where it happens.

For a longer walkthrough of the product, see my v0 tutorial.

Manus

Manus has iOS and Android apps, alongside its browser interface. It can build web applications, including their backend and database, through a conversation.

Install the app from the official download page and sign in to your Manus account. Describe the application you want, inspect its preview, and request changes. Its app-building guide documents continuing the same project across your computer and phone.

For example, I would start with a reading list that saves a title and URL. Once that works, I would ask for an unread filter, then try adding and filtering entries from the phone before requesting another feature.

The development environment belongs to the Manus project. This route doesn’t attach to an arbitrary coding session already running in your terminal.

Manus also builds mobile applications. Keep that separate from using Manus on your phone: one describes the output, the other describes how you operate the agent. Check the publishing requirements for your target platform before planning a store release.

I would compare it with Replit or Lovable for starting an app through prompts. If the goal is to continue a specific local repository with its existing tools, I would choose a remote connection to that machine instead.

Devin through Slack

Devin’s Slack integration gives you another mobile entry point. Once your organization connects it and you link your user profile, mention @Devin with a task.

The session replies in the thread with progress and questions. You can continue that conversation from Slack on your phone.

This fits work that starts in a team conversation. Someone reports a broken filter, you add the steps to reproduce it, and Devin can investigate from that thread.

I would include the repository and expected result explicitly. A conversation may contain several suggestions and side discussions, and the agent needs to know which change you approved.

The Slack app is the interface here. The development work happens in Devin’s session environment, so your phone doesn’t need a local checkout.

Happy

Happy adds a mobile interface to agents running on your hardware. It also offers a desktop harness, but its terminal workflow can be used without the desktop app.

Its documented CLI entry points include happy claude and happy codex. Start through Happy on the computer, then use the mobile companion to reach the session.

Happy says communication between devices is end-to-end encrypted. You still need to keep the computer and its agent available.

I would consider it when I want a shared mobile interface across agents rather than switching between each vendor’s app.

Check its current provider support before installing. A companion interface has its own compatibility requirements, separate from the underlying agent’s subscription and permissions.

HAPI

HAPI wraps coding agents and exposes sessions through native iOS and Android clients, a web/PWA interface, or a Telegram Mini App.

Its supported-agent list includes Claude Code, Codex, Cursor Agent, OpenCode, Copilot, and Pi, among others. The native clients are documented in the repository, including build and pairing instructions. Check those instructions rather than assuming every client is an App Store download.

The hub connects your remote interface to the machine running the agent. From the phone you can follow work, send messages, and respond to approval requests.

I would consider HAPI for a setup where I want to operate the hub myself and use several agents through it. That adds a service to maintain, so compare it with the built-in remote access your preferred agent already provides.

OpenClaw through messaging apps

OpenClaw connects messaging apps to agents through a gateway you run on your computer or server. You can send a task from Telegram or Discord on your phone and receive the agent’s replies in the conversation.

Set up the gateway using its onboarding guide, connect the channel you want, and restrict access to the people who should be allowed to use it. The gateway host must stay online.

For coding work, its ACP integration can run external coding agents such as Claude Code or Cursor. OpenClaw routes the conversation; the coding agent uses its own tools and authentication.

The ACP quickstart covers installing the runtime plugin and checking it with /acp doctor. Install and authenticate the chosen coding agent on the host, give it access to the project, then use the documented conversation-binding setup for your channel.

OpenClaw has a separate native integration for controlling Codex sessions through /codex commands. Follow that integration’s instructions if Codex is your target; the ACP route isn’t its default path.

I would try this when I want to send a small coding task from a messaging app I already use. A bound conversation lets me return to the same work and give it another instruction without opening a separate agent client.

There is more setup to maintain here than with a hosted mobile app. Check the gateway’s access rules and the coding agent’s permissions, including how an approval reaches your phone. If a command waits for a terminal prompt you cannot see, the conversation can appear idle while the agent is blocked.

OpenCode’s browser interface

OpenCode includes a web interface. Run this on the computer that holds the project:

opencode web

By default it listens on the local machine. Your phone needs a secure route to that server before it can connect.

The documentation warns that the server is unsecured unless you set OPENCODE_SERVER_PASSWORD. Configure authentication before allowing network access, and use a private network or an authenticated HTTPS setup for remote access.

Once connected, the browser gives you access to sessions on the host. A terminal can attach to the same server, so you can use both interfaces with shared session state.

I would choose this when I already use OpenCode and want to keep its existing projects and provider configuration. My OpenCode guide covers the agent itself.

SSH with Termius, Blink, Herdr, or tmux

A mobile SSH client gives you access to terminal agents on a server or another computer you control.

Termius has iPhone and Android clients. Blink Shell is another option on iPhone and iPad, with SSH and Mosh support.

Once connected, you can run a coding CLI in the remote shell. This route also works for tools without a dedicated phone interface, provided they run on your host.

For example, Google Gemini CLI brings Google’s coding agent into a terminal. Mistral Vibe Code also offers a CLI for a local checkout. Install and authenticate them on the remote computer, then reach that terminal from your phone. The Gemini or Le Chat chat app is a separate interface from this CLI workflow.

Use a persistent session manager so a dropped phone connection doesn’t take your working terminal with it. My Herdr phone guide covers setup and reconnection. tmux is another option.

The pieces serve different purposes:

A session manager doesn’t make the server survive a reboot. Keep the repository backed up and know how to resume the agent after a restart.

If SSH is new to you, my free SSH course covers keys, host verification, and connection setup.

A hosted development machine can save you from maintaining a computer at home. exe.dev provides persistent Linux machines and a browser-based agent. It is another place to keep the development environment while the phone acts as your interface.

Running an agent on Android with Termux

Termux provides an Android terminal environment with packages such as Git, OpenSSH, and Node.js.

You can use it as an SSH client, keeping the agent on a remote host. You can also experiment with running an agent program on Android itself, when its dependencies support that environment.

Check compatibility first. A desktop CLI can depend on native binaries built for a different operating system. Having Node.js installed doesn’t guarantee that every agent package will work.

With local execution, the phone holds the checkout and credentials. Android’s Doze and App Standby can defer background CPU and network activity, so test with the screen locked before depending on a long run.

I would start with Termux as an SSH client. Local Android execution is worth exploring when you specifically want the development files on the device and are prepared to handle compatibility.

Give the agent a task you can review

A phone makes the size of a change obvious. Reading a two-file bug fix is manageable. Reviewing a broad refactor while switching between files is much harder.

Give the agent a clear boundary. For example:

Find why the reading-list page shows an empty heading.
Explain the cause, then fix only that behavior.
Add a test for an article with no title.
Run the relevant tests and show the changed files.
Leave the change ready for review.

Ask for the evidence you need. For a UI change, request a preview link and a screenshot of the changed state. For a bug, ask which test reproduces it and whether that test now passes.

A screenshot shows appearance. You still need to use the flow. Open the preview on your phone, try the controls, and check what happens when an input is empty or invalid.

Voice dictation can save typing, but reread file paths and product names before sending. A wrong word can send an agent looking in the wrong place.

Check the destination and permissions

Before starting a task, confirm the repository, branch, and execution environment.

A cloud checkout may not contain uncommitted changes on your laptop. A remote session may have access to credentials or services that a cloud environment lacks.

That affects what you can ask it to do. A task that passes tests in the cloud may still need local verification. A task on your computer may be able to touch resources beyond the repository, depending on its permissions.

Keep approval requests readable. If you cannot understand a command or assess a large diff on the phone, leave it waiting until you can inspect it properly.

Also check billing separately. Some products use subscription limits, some meter agent work, and a self-hosted interface may still call paid model APIs. A free mobile client doesn’t make the underlying work free.

Test the return trip before relying on it

Start a harmless task, lock the phone, and reconnect later. Confirm that you return to the same session and can see its changed files and test output.

Then switch from Wi-Fi to mobile data. Check whether you can still reach the host or cloud session.

Try a failure too. Ask the agent to run a harmless failing test and verify that you can read the error, send a correction, and stop the run from your phone.

For a remote computer, test what happens when it sleeps. For a cloud agent, check how long an idle session remains available. These are different failure cases, and you want to discover them during setup.

How I would choose

I would first try the mobile interface of the agent I already use. That keeps the first experiment small and avoids adding another service before I know what is missing.

My first real task would be a small fix in a project I know well. I would send it from the phone, review the result there, and finish the review at my desk. That gives me a concrete way to find what the mobile workflow makes easy and what still needs a larger screen.

Want me to talk about your product? You can sponsor this site.