Module codex_peer 

Live stock-Codex session discovery.

Codex does not publish a peer registry or a supported attachment endpoint, but its process keeps every rollout it currently owns open. This module joins that process-owned file descriptor back to the persisted catalog path. The rollout’s last explicit lifecycle event then distinguishes an executing turn from a merely running session. No timing or CPU heuristic is used.

A turn waiting on an approval writes nothing to its rollout: the request goes to the app-server’s connected client and, when that client has gone, to no one, so the rollout reads as a turn still executing. For the threads Codex’s shared app-server daemon has loaded, its own thread/read status (active with waitingOnApproval or waitingOnUserInput) is asked over the daemon’s control socket and wins over the rollout.

Enums

CodexPeerStatus

Activity proven for a rollout owned by stock Codex.

Functions

holds_session

Whether pid holds the rollout of Codex session session_id open.

launched_session

The Codex conversation a launch in cwd started: the newest root rollout under sessions_root (YYYY/MM/DD/rollout-*.jsonl) written since since whose first record names cwd. A launch is bound by this record of its own rather than by the process, open-file and pane chain, which missed both Codex launches of 2026-10-02 within a minute though their rollouts existed in two.

live_rollouts

Every Codex rollout currently held open by a stock codex process, with the narrowest activity state its own event stream proves.

resumed_session_of_process

The conversation a codex resume <id> process continues, read from its command line: a resumed conversation that has not written since holds no rollout open, so the rollout cannot name it.

rollout_cwd

The working directory a rollout’s conversation runs in, from its first session_meta record.

rollout_of_session

The rollout file of conversation session_id under Codex’s sessions root (YYYY/MM/DD/rollout-…-<id>.jsonl).

rollout_session

A rollout’s session id and, for a subagent thread, its parent’s id.

rollout_status

Activity for a discovered catalog path owned by a currently running Codex.

session_of_process

The Codex session a process runs: the root rollout (one with no parent thread) among the files pid holds open, as (session id, rollout path). None when pid holds no Codex rollout.

session_panes

The machine daemon pane each Codex conversation runs in, by session id. The pane the daemon names in the environment it gives every pane (SUPERCODE_TEAMS_PANE), read from the codex process that holds the conversation’s rollout, is only a candidate: a process inherits that variable from whatever ran it, so a headless codex exec a Claude pane’s tool started carries the Claude pane’s name, and its mail was typed into Claude’s composer (twins’ m-72bc65eb). A Codex holds a pane only as that pane’s own program: the pane’s root process by the daemon’s record, or a descendant of the root reached only through Codex launchers (npm’s codex.js runs the native codex beneath it, and the daemon’s Codex pane host runs that beneath itself: yuerans-macbook-pro’s node native-codex-pane.mjs → node codex.js → codex, 2026-10-03), when the root is itself a Codex launcher or the daemon launched the pane as Codex. A root that is Claude does not lend its pane to the codex exec a tool of it runs: the tool’s shell is no launcher, and the daemon launched that pane as Claude. A conversation outside any daemon pane (or held only by the shared app-server) has none.

session_processes

Each running Codex conversation’s own process (session id → pid): the root rollout a codex process holds open, or the conversation its resume <id> names. A shared app-server holding several conversations names none of them.