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.
4. Advisor mode: the session asks back. A skill teaches Codex to
   raise hard-to-reverse decisions (test architecture, schemas,
   dependencies) as marked requests in its own output; Pro answers into
   the queue. Supervision stays what it was, this is an extra direction.

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.

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.

Advisor mode - the session asks, Pro answers

Supervision runs one way: Pro watches and steers. Advisor mode adds the
opposite direction: mid-implementation, the session puts an architecture
decision in front of Pro and acts on the verdict. Built for the calls a
coding agent otherwise makes alone and you only catch in review - test
design, schema changes, dependency choices.

No new plumbing. The question is a marked block in session output, which
Pro reads like everything else; the answer is a normal queued message.
The whole mode is two contracts:

1. skill/ask-advisor/SKILL.md goes on the
   session side:

   cp -r skill/ask-advisor ~/.codex/skills/ask-advisor
   

   It tells the agent which decisions deserve an advisor (hard to
   reverse, crosses modules, changes contracts or test architecture),
   which do not, how to format the request, and to keep working on
   independent tasks while waiting instead of blocking.

2. SUPERVISOR.md tells the supervising chat how to
   spot a request and answer it: one message, one decision, what to
   verify before acting.

The session cannot poll ChatGPT - Pro has no API, which is why this
bridge exists at all. The answer lands whenever the advisor next reads
the session: minutes when you have the chat open, a schedule tick when
a scheduled task does the reading. The skill covers the gap: park the
question, continue independent work, and if no answer comes, proceed
with the stated leaning in the most reversible way and mark the decision
provisional.

The advisor does not have to be Pro. Any MCP client pointed at the
bridge, Claude included, can read requests and answer them - so you can
also A/B your advisors on the same session and keep the one that makes
better calls.

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.