Managing Claude Code and Codex from My Phone: What I Actually Needed

The small decisions that kept me returning to my computer, and what I now check before trusting a phone with them.

Cover: AI-generated illustration of checking coding-session status from a phone. The interface is illustrative, not an AigoPilot screenshot.

I would leave the house expecting an AI coding task to make progress while I was away. Later, I would discover that it had stopped shortly after I left.

Sometimes a usage limit interrupted the work. Other times a session needed permission or had reached a question I needed to answer. From my side, the result was similar: time had passed while the work waited.

I work across several software projects, so checking one conversation was only part of the problem. I needed to find the session that required attention, understand why it had stopped, and decide whether I could help it continue from my phone.

Those experiences changed how I supervise coding sessions when I'm away from my desk. What I wanted was a short route from an interruption to the decision behind it.

Opening a session should show what just happened

In some mobile setups I used, opening a conversation initially showed the state I had seen on my previous visit. Newer prompts and results arrived afterward. I sometimes waited five to ten seconds. On other occasions, a Retry message sent me back to the computer.

These were experiences with particular versions and configurations. The native tools continue to change; this is an account of the friction that influenced my own workflow, not a comparison of their current feature lists or a benchmark.

The delay mattered because I was opening the session for a reason. Had the task finished? Had something failed? Was a permission request still waiting?

A conversation displaying older information could not answer those questions yet. Reopening it repeatedly added uncertainty about whether I was looking at the latest state.

So freshness became one of my priorities. I wanted the current result close to hand, without scrolling through a long conversation to work out where the task had reached.

Fast loading alone would not solve the whole problem, though. The screen also needed to explain the state of the task.

A completed response can still leave work waiting

A session can finish its response with a report that needs no immediate action. It can also finish with a question: should it run another check, continue with the next step, or choose between two approaches?

Both have produced a response. They ask different things of me.

If a task is complete, I can often read the result later. If the next action depends on my answer, postponing that message can leave the session idle. A permission request is another case: I need to understand the proposed action before deciding whether to allow it.

This is the checklist I use when thinking about those interruptions:

This is a design checklist, not a claim that software can classify every conversational ending perfectly. A clear result should still be available for me to inspect.

The purpose of a notification is to help me choose what deserves attention now.

The tap needs to end inside the right conversation

With several projects and many accumulated sessions, a generic "your agent needs you" notification leaves another task for me: finding the agent.

I want a notification to identify the project and session, then take me directly to the place where I can respond. A mobile workflow loses much of its usefulness if I have to reconstruct the route through project lists and conversation tabs each time.

That requirement also changed how I thought about finding sessions.

Finding an earlier session by what it built

I often wanted to return to the session that had built a particular feature. Its title might reflect how the conversation began, while the feature I remembered was developed much later. Searching titles alone was unreliable in my own work.

In my setup, I describe the feature and the project by voice instead. If one session matches, it opens. If several are plausible, I see a short description of each and choose.

The destination matters. Receiving an internal session ID would still leave me working out how to open it. I want the search to end with the conversation ready to continue.

Returning to the earlier session can preserve useful context, although I still need to check the current code. The project may have changed since that session worked on the feature.

Sometimes I want to start something new

Continuing an existing task covers much of my phone use. I also wanted to create a project while away from the desk.

That involves more than opening a blank chat. The project needs a location on a connected computer: a drive, a folder, and possibly a new subfolder. Then I need to create a session and choose the AI tool I intend to use.

Having those choices on the phone makes it useful before a coding conversation exists.

This applies with a single provider too. Someone with only a Codex subscription can still have several projects and sessions, need useful notifications, and need a route back to the correct task.

The connected computer remains responsible for execution. It needs to be reachable and ready for the project. Choosing a folder from a phone does not supply a missing compiler, application, or dependency.

I ran into that when moving a Unity project to a spare laptop. Preparing the destination environment became part of the work.

Know what a phone can review and what needs a desk

A short follow-up instruction or a clear permission request may be manageable from a phone. A substantial code change, an unfamiliar operation, or a difficult interface bug can require a larger screen and more time.

I do not treat every notification as something I should clear immediately. I want enough context to decide whether to act now or return to it at my desk.

A usage-limit interruption needs different handling from a permission request. A notification can explain that the task has stopped; it cannot remove the provider's limit. I want that distinction to stay visible instead of treating every pause as an unanswered question.

Test the whole path before relying on it

This is a procedure I propose, not a set of results I'm reporting. I would evaluate any mobile setup with a small development task before relying on it while away:

1. Start the task on the intended computer.
2. Open its session from the phone and check that the latest state appears.
3. Respond to a legitimate request that you understand.
4. Confirm that the response reaches the correct session and execution continues.
5. Check the resulting change on the computer where the work ran.

I would also check what happens after connectivity is interrupted. Seeing your message in the phone interface is useful evidence, but it does not prove the action reached the right computer. Confirming the result on that computer completes the check.

A shorter route back to useful work

For my own workflow, the value of the phone comes from small, specific actions: finding a session, checking its current result, answering a question, or starting a project on an available computer.

Each interaction should leave me with a clear outcome. Either the work can continue, it has finished, or I understand why it needs to wait.

Before choosing a mobile arrangement, try that complete route with the tools already available in your account. The setup worth keeping is the one that reliably connects the notification, the decision, and the actual session doing the work.

I'm Anoosh Ohadi, founder of AigoPilot. This article draws on my own development experience and was prepared with AI assistance. The cover is an AI-generated illustration.

For the broader story behind this workflow, see My Claude Code and Codex Workflow: The Problems I Had to Solve Myself.

Originally published on Medium.