codex-remote-pro

Steer a running Codex CLI session from ChatGPT - at your desk or from your phone. The supervisor reads what the session is doing and sends instructions straight back. The session keeps running in your terminal: nothing restarts, nothing gets screen-scraped. And the model doing the supervising no longer has to be one Codex offers.

GPT Pro (desktop) / ChatGPT mobile / ChatGPT scheduled tasks
        -> connector -> tunnel -> local bridge (127.0.0.1) -> your `codex` session

What you get:

1. GPT Pro supervises Codex. Pro used to be a third view you pasted updates into. Connected, it reads recent session output itself, keeps the overview, and drops plans or corrections into the session as normal user turns. Codex executes, Pro plans. No more copy-pasting between two models.

2. Phone access, free. Connectors are account-level, so the same tools show up in the ChatGPT mobile app with no extra setup. Ask "what's happening with the session?" from the gym, read the latest work, steer from anywhere.

3. Overnight supervision. ChatGPT scheduled tasks can call the connector too: a task you set up in the ChatGPT app reads the session on a schedule and messages it only if steering is needed - while you sleep. See below for how.

Setup - point your coding agent at this

The local half is agent-friendly: paste this into Claude Code, Codex, or any coding agent on the Mac where Codex runs.

Set up codex-remote-pro from https://github.com/Vuk97/codex-remote-pro

Requirements: macOS, Python 3.10+, codex-cli >= 0.150 (check `codex --version`),
cloudflared (`brew install cloudflared`).

1. git clone https://github.com/Vuk97/codex-remote-pro && cd codex-remote-pro
2. python3 -m venv .venv && .venv/bin/pip install -e ".[dev]"
3. .venv/bin/codex-remote token generate
4. Start the daemon in the background: .venv/bin/codex-remote daemon
5. ./scripts/selftest.sh   - must print PASS, stop and debug if not
6. .venv/bin/codex-remote discover   - find my running codex session's thread uuid
7. .venv/bin/codex-remote adopt --session main --thread <uuid from step 6>
8. Confirm reads work: .venv/bin/codex-remote read main --limit 4000
9. ./scripts/bridge-up.sh then ./scripts/bridge-url.sh - give me that URL
10. Open docs/CHATGPT-SETUP.md and walk me through the ChatGPT connector
    creation. The browser clicks are mine; you provide the values.

Steps 1-9 need no human input. Step 10 is account clicks in ChatGPT - docs/CHATGPT-SETUP.md covers every screen and every gotcha (connector URLs are immutable, name collisions fail silently, the fastest model tier refuses to call tools, and three more).

Last piece: paste SUPERVISOR.md into the ChatGPT project that will do the supervising. It makes Pro re-check the session generation before every write and read before it steers.

Related MCP server: codex-cli-mcp

How it works

Writes go through codex queue, a first-party codex-cli subcommand, so a message enters the session's queue the same way typing does. A running session is adopted in place - no restart. Reads are bounded cursor slices of the session's rollout file. ChatGPT gets five tools, nothing else:

No shell, no filesystem. Write guards: a restarted session gets a new generation and stale sends are rejected; retries with the same idempotency_key are never delivered twice; unknown or exited sessions get typed errors; every call is logged with a hash of the message, never the body.

Scheduled tasks (queued jobs)

You set up scheduled tasks in the ChatGPT app - there is no API for creating them. Give the task a prompt written for the specific job, because a "watch the overnight refactor" prompt is not a "check if tests went green" prompt. Any such task can use this connector to read the session and write to it on the schedule you chose. Build the prompt from SUPERVISOR.md: list sessions first, read with cursors, send only if steering is needed.

Set the connector permission to "Allow all actions": supervision means sending messages, and a scheduled run cannot tap a confirmation card at 3am. On "Allow read actions" every send stalls until you approve it by hand - fine for a first look, useless overnight.

Trust

This gives a cloud service a write path into a local coding agent. The path is text-only: the worst a compromised supervisor can do is send a message, which Codex handles under its own sandbox and approval settings. Bearer auth on every request, 127.0.0.1 bind, unguessable URL. Optional: deploy vercel-proxy once and your connector URL survives tunnel restarts and reboots.

codex queue, the rollout layout, and pid binding are not documented stable interfaces. Tested against codex-cli 0.150.1 and 0.151.0. If a future release breaks it, the bridge fails with typed errors instead of guessing. After a reboot, codex-remote readopt --all re-binds sessions to the new codex process (scripts/bridge-up.sh does it automatically).

Take it further

This solves the pain points it was built for, and stops there. The idea is bigger than the implementation:

• Any supervisor model, any lab. The bridge is a plain MCP server (streamable HTTP + bearer token). ChatGPT is just the first client: point Claude or anything else that speaks MCP at the same URL and let whatever model you prefer do the supervising.

• Multiple advisors. Reads are cursor-based and writes are queued as ordinary user turns, so nothing limits you to one supervisor - a planner and a reviewer can watch the same session side by side.

• Other harnesses. The pattern - adopt a running session in place, bounded reads, one narrow write path - is not Codex-specific. The plumbing here is codex queue plus rollout files, but the same five tools could front any terminal coding agent.

Fork it and go. PRs welcome.

Layout

src/codex_bridge/   server, service layer, registry, transports, CLI
tests/              29 tests incl. fake-PTY end-to-end
scripts/            bridge-up, bridge-url, selftest
vercel-proxy/       optional permanent-URL gateway
SUPERVISOR.md       operating contract for the supervisor chat
docs/               ChatGPT setup, click by click

MIT.