Introduction
The shortest answer: use OpenAI's native mobile Remote tab when your work lives in a supported Codex desktop chat. Use a tmux-level controller when you need to reach an arbitrary Codex CLI process or manage Codex beside Claude Code, OpenCode, and shell jobs.
OpenAI now lets the ChatGPT mobile app connect to active Codex work on a laptop, devbox, or remote machine. You can review terminal output, diffs, tests, screenshots, and approvals while the files and credentials remain on the machine. That is the cleanest path for a Codex-native workflow.
There is an important boundary. OpenAI's current help page says Codex is not a selectable mobile experience. Supported desktop Codex chats appear in the mobile app's Remote tab. Do not assume that every standalone codex process already running in a terminal will be imported into that list.
This guide compares the native path with ClawTab Remote, which controls the local tmux pane itself. That lower-level boundary matters when the process is Codex CLI, when several agent providers share a workspace, or when scheduled shell jobs need the same phone interface.
What OpenAI's Codex Mobile Remote Control Does
OpenAI describes Codex in the ChatGPT mobile app as a live view into trusted machines where Codex is working. The phone can load active threads and project context, show output as it arrives, and let you approve commands or change direction. OpenAI says screenshots, terminal output, diffs, test results, and approvals can flow back to the phone.
The execution boundary stays on the connected machine. Files, credentials, permissions, and the local toolchain do not move onto the phone. A secure relay keeps the machine reachable without requiring you to expose it directly to the public internet. See OpenAI's announcement, Work with Codex from anywhere, and the current ChatGPT Work and Codex help page.
| Native Codex mobile capability | What it means in practice |
|---|---|
| Remote tab in ChatGPT mobile | Open supported Codex chats from a phone; Codex is not a separate selectable mobile mode. |
| Live machine state | Follow active threads, terminal output, tests, diffs, screenshots, and approvals. |
| Local execution | The repository, credentials, tools, and permissions stay on the laptop or remote machine. |
| Secure relay | The trusted machine does not need a public inbound terminal port. |
| Codex-native scope | The mobile surface is designed around supported Codex chats, not every process in a tmux server. |
Codex Mobile vs ClawTab Remote
The products overlap at the phone, but they attach at different layers. OpenAI owns the Codex conversation and can present structured Codex artifacts. ClawTab owns the local tmux workspace and can present the terminal processes running inside it.
| Question | Codex mobile Remote tab | ClawTab Remote |
|---|---|---|
| What does the phone attach to? | A supported Codex desktop chat | A local ClawTab and tmux workspace |
| Providers | Codex | Codex CLI, Claude Code, OpenCode, and shell panes |
| Structured Codex artifacts | Threads, diffs, tests, screenshots, approvals, and project context | Live terminal state, detected questions, pane input, job state, and schedules |
| Arbitrary existing tmux pane | Not the documented attachment model | Yes, when the pane is part of the ClawTab workspace |
| Scheduled local jobs | Use Codex's supported scheduling surfaces | Standard cron-backed ClawTab jobs share the same remote view |
| Machine needs to stay reachable | Yes, for work executing on that machine | Yes; tmux survives terminal disconnects, not machine sleep or power loss |
Choose the native Codex path when one provider owns the whole workflow and its structured review experience matters. Choose ClawTab when the operational unit is a local pane rather than a provider conversation. The broader local versus cloud coding agent comparison covers what changes when the task should run independently of your workstation.
A Real Local-Agent Approval Flow
A remote-control system earns its keep at the blocking point. The agent asks for permission or a choice, the phone shows enough recent output to make the decision, and the answer returns to the same local process.
The screenshot below shows ClawTab detecting interactive questions in local tmux panes and rendering the active prompt as mobile buttons. This captured run uses Claude Code, which makes the prompt boundary easy to see. The transport itself is pane-based: Codex CLI and OpenCode panes use the same live-output and input route, while prompt parsing adapts to the terminal UI each provider emits.
Set Up Phone Access Without Publishing a Terminal
Do not solve this by forwarding SSH or a raw terminal port to the internet. Both the native Codex route and ClawTab use an outbound relay model so the development machine stays behind its normal network boundary.
- Pick the attachment layer. Use the ChatGPT mobile Remote tab for a supported Codex desktop chat. Use ClawTab when the target is a Codex CLI or other process in tmux.
- Keep the repository on the machine that runs the agent. Start the job in the intended checkout or, for multiple writers, a dedicated Git worktree and tmux pane.
- Connect the mobile client through the product relay. Sign in to ChatGPT mobile for native Codex access, or pair the ClawTab iOS/web client with the desktop app.
- Test a harmless approval. Ask the agent to run a read-only command that requires confirmation. Verify that the phone shows the command and enough surrounding output before allowing it.
- Test reconnection. Detach the terminal, switch the phone between Wi-Fi and cellular, and confirm that the same thread or pane returns.
tmux preserves the process when the terminal disconnects. It does not keep a sleeping or powered-off Mac online. If the job must continue with no dependency on your machine, use a hosted Codex task instead of remote control of a local process.
Use One Phone View for Codex, Claude Code, and OpenCode
Provider-native remote control is usually the best client for that provider. The trade-off appears when a workspace contains more than one agent type.
A common local setup has Codex reviewing one worktree, Claude Code implementing in another, OpenCode handling a smaller task, and ordinary shell panes running tests or a local service. Opening separate provider apps does not show whether the full workspace is healthy. A tmux-level view does.
- One process boundary: each agent remains an ordinary tmux pane with its existing CLI state.
- One mobile queue: waiting prompts from different panes appear together instead of being split by provider.
- One scheduling layer: cron jobs and interactive agents can share the same local machine and remote status view.
- One permission policy per pane: use manual approval by default, then enable auto-yes narrowly for a trusted, isolated task.
This is the main reason to add ClawTab around Codex CLI. It does not replace Codex's models, reasoning, diff review, or native mobile experience. It gives several local tools one operational home.
Claude Code Has a Native Remote Path Too
Claude Code Remote Control is the closest provider-native comparison. Anthropic's current documentation says it connects a local Claude Code CLI or VS Code session to claude.ai/code and the Claude mobile app. Execution and filesystem access remain local. The session makes outbound HTTPS requests and does not open an inbound port.
Claude's native path supports browser and mobile conversation sync, permission handling, file attachments, push notifications, and multi-session server mode. For a Claude-only workflow, use it. See Anthropic's Remote Control documentation.
Use ClawTab when the boundary is broader than Claude: mixed providers, existing tmux panes, shell processes, cron schedules, or one phone queue for the whole local workspace. This is the same decision as Codex native versus ClawTab—provider conversation versus terminal control plane.
Security Questions to Answer Before Leaving the Desk
Remote control keeps execution local, but it expands who can approve local actions. Treat the phone as a privileged development client.
- What is exposed? Prefer an authenticated outbound relay. Do not publish tmux, SSH, or a web terminal directly.
- Where does session data live? Read the provider's retention policy. Local execution does not mean that every message, transcript, or artifact stays only on the workstation.
- What can one approval do? Keep sandboxing and least-privilege credentials enabled. A phone-sized screen is a poor place to approve a long destructive command.
- Can you identify the target? Name each project, worktree, and pane clearly so an approval cannot land in the wrong repository.
- What happens after theft? Require device authentication, keep account recovery current, and revoke the mobile session immediately if the phone is lost.
ClawTab connects its desktop and mobile clients through TLS and a relay rather than opening an inbound terminal port. The existing remote access guide covers its connection model, push notifications, and self-hosted relay option in more detail.
Which Remote Coding Agent Setup Should You Use?
| Your actual requirement | Start here |
|---|---|
| Review and steer supported Codex desktop work with native diffs, tests, and approvals | ChatGPT mobile Remote tab |
| Continue one or more local Claude Code sessions from mobile or browser | Claude Code Remote Control |
| Reach a standalone Codex CLI process already running in tmux | ClawTab Remote |
| Monitor Codex, Claude Code, OpenCode, and shell panes together | ClawTab Remote |
| Run when the laptop is asleep or disconnected | Codex cloud or another hosted agent environment |
| Operate a production service with no interactive prompts | A process supervisor and deployment tooling, not a coding-agent phone UI |
Start with the provider-native client when it covers the whole job. Add a local control plane only when the terminal session, tmux workspace, or mixed-provider queue is the real source of truth. For a wider tool comparison, see the guide to multiple AI coding agents and managers.
