Feature: Claude Code-style `monitor` tool with first-class remote-host support

Summary

Please add a first-class monitor capability to Codex, similar to Claude Code's Monitor tool, with remote-host execution as a core requirement.

There is already a strong proposal for an agent-callable monitor in #29922. The missing piece I want to emphasize is remote development: when Codex is operating against a remote Linux machine / remote workspace, the watcher should run on that remote host, not on the local Mac/desktop process.

This matters a lot for ML / robotics / systems workflows where the expensive work actually runs on remote GPU servers.

Desired behavior

A Codex session should be able to do something like:

monitor(action="start", command="tail -F train.log | grep --line-buffered -E 'OOM|NaN|Traceback|eval finished'", description="training status")

and then:

1. start the watcher in the currently selected remote execution environment;
2. let the Codex session become idle without polling or burning turns/tokens;
3. keep the watcher alive while the remote job continues;
4. wake the same Codex session when the watcher emits an event;
5. allow the agent to inspect the new state and continue debugging automatically;
6. expose list / stop for active monitors;
7. clearly show whether each monitor is running local or on a particular remote host/session.

Remote-host requirements

For remote workflows, I would like the monitor lifecycle to be tied to Codex's remote execution abstraction rather than to a local shell process.

Concretely:

• monitor commands should execute on the same remote host/container/workspace where Codex commands are being executed.
• File watchers should observe the remote filesystem (inotifywait, tail -F, etc.).
• Process/job watchers should observe remote processes, training jobs, servers, Slurm jobs, Docker containers, etc.
• A local UI becoming idle should not terminate the remote watcher.
• Ideally, temporary client disconnects / SSH drops should not silently destroy the watcher; the session should be able to reconnect and recover monitor state when practical.
• Events should wake the visible Codex session, rather than only a hidden/headless thread. This overlaps with the live-session wake problem discussed in #33556.

Example use cases

Remote training

Start the training job on gpu-server-03 and monitor the log.
If OOM / NaN / traceback appears, wake up, diagnose it, patch the config/code, and continue.

Long evaluation

Run the benchmark remotely. Monitor until evaluation finishes, then summarize the metrics and compare them with the previous run.

Remote service debugging

Start the server in Docker on the remote machine and monitor its logs for errors while I work on something else.

Slurm / cluster jobs

Submit the job and monitor `squeue` / job logs. Wake when the state changes to FAILED / COMPLETED or when a target metric appears.

Why polling is not enough

Today an agent can approximate this by repeatedly checking logs/process state, but that is inefficient and fragile for jobs that may take minutes or hours. The desired primitive is event-driven:

remote process / log / file event
        ↓
remote monitor
        ↓
Codex session wakes
        ↓
agent continues reasoning / debugging

This is especially useful for Codex because remote compute is common in software engineering, ML training, robotics simulation, and scientific workloads.

Relationship to existing issues

• #29922 — proposes the core agent-callable monitor tool. I strongly support that proposal; this issue is specifically about making remote-host semantics first-class, not an afterthought.
• #33556 — discusses delivering async/external events into the live visible session.

If maintainers prefer, this can be treated as an extension / acceptance criterion for #29922 rather than a separate implementation track.

Expected UX

The ideal user experience is essentially Claude Code Monitor parity, but with Codex's remote environments integrated cleanly:

Codex: training is running remotely; I am monitoring train.log.

...session is idle...

[monitor: gpu-server-03 / training status]
RuntimeError: CUDA out of memory

Codex automatically wakes and starts diagnosing the failure.

That would make Codex substantially better for long-running remote development and research workflows.

Start by reading proposals #29922 and #33556, then trace the remote execution abstraction and live-session event/wake path described here. Done means monitors can start, list, and stop on the selected local or remote environment, survive idle sessions, and wake the visible Codex session when remote events occur.