# Codex Babysit

> Monitor and keep alive a long codex goal-mode session that is already running in a tmux pane, until codex's own goal genuinely completes. Watch the pane for usage limits, stalls, or process death; on a real usage limit rotate the aim account (`aim status` then `aim codex use <label>`), then kill, restart, and `codex resume <session-id>` the SAME session, clear the 'Resume paused goal?' menu, and verify it ACTUALLY resumed work on the new account; check on a ~15-min cadence via a background poll, never a tight loop. Use when the user says monitor/babysit/watch/keep-running my codex, keep it going across rate limits, or restart-and-resume it when limited. Not for spawning a worker to do a task (`agent-delegate`), running your own goal-seeking loop (`goal-loop`), a one-off codex review (`codex-review-yolo`), or purging ~/.codex state (`codex-cleanup`).

- Skill: `aelaguiz/codex-babysit` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add aelaguiz/codex-babysit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aelaguiz/codex-babysit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: aelaguiz (https://skillmd.com/u/aelaguiz)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/aelaguiz/codex-babysit

---


# codex-babysit

Use this skill when a `codex` session is **already running a long goal** (goal-mode,
footer shows `Pursuing goal`) inside a tmux pane, and the user wants it kept alive
across usage limits, stalls, and restarts until that goal genuinely finishes —
often unattended for hours.

This skill is a **watchdog, not a worker**. It does not do codex's task and does
not launch the session. It watches the pane, decides when codex is actually stuck
versus just slow, rotates the aim account when codex hits a real usage limit,
restarts and resumes the *same* session, and proves work resumed — on a cadence
that does not burn your own context. The hard parts are all judgment: telling a
real limit from a transient blip, an idle-because-done from an idle-because-stuck,
and "restarted" from "actually resumed work."

Read `../_shared/agent-orchestration-policy.md` for the shared continuation and
transport vocabulary. This skill is an intentional durable-session boundary,
not an agent-transport selector: it only observes and resumes the exact Codex
session the user already started.

## When to use

- The user says "monitor / babysit / watch / keep running my codex", "keep it
  going when it gets rate limited", "restart and resume it if it hits a usage
  limit", or "make sure my long codex goal finishes overnight".
- A codex goal-mode session is live in a known tmux pane and the work will outlast
  one account's usage window, so account rotations will be needed.
- The user wants hands-off continuity: codex should keep making progress even as
  individual accounts hit their 5h/weekly caps.

## When not to use

- You need to launch a new task worker. Prefer the active host's native child
  when it can do the job; use `agent-delegate` only for a deliberate external
  worker/session benefit.
- You want to run *your own* goal-seeking loop where you make the bets →
  `goal-loop`.
- You want a one-off external review from codex on an artifact → `codex-review-yolo`.
- You need to clean bloated `~/.codex` state → `codex-cleanup`.
- There is no live codex session/pane to watch yet. Start it (or have the user
  start it) first; this skill keeps an existing session alive, it does not create one.

## Non-negotiables

- **Judge state from the PANE, not from aim percentages.** `aim`'s `5h_full` /
  100% is a *leading accounting flag*, not a hard block — codex keeps working past
  it until the API actually refuses a request. Rotate on real pane signals only.
- **Rotate only on a real usage limit or process death.** Never rotate on a
  transient `Reconnecting...` — it self-heals. Distinguish the two before acting.
- **A process restart is REQUIRED after `aim codex use`.** codex reads
  `~/.codex/auth.json` once at startup and caches it; swapping the file does
  nothing to the running process. Account change ⇒ restart.
- **Resume the SAME session id** (`codex resume <SESSION_ID>`), which appends to
  the same rollout and preserves the goal and history. Do not start a fresh session.
- **Do not repurpose the handle.** Exact-session resume is correct because the
  same durable goal continues. Never use the watched session for unrelated
  delegated work, a cold critic, or a new role.
- **"Restarted" is not "resumed work."** After resume, the goal does not
  auto-resume: clear the "Resume paused goal?" menu (Enter on option 1) or send
  `/goal resume`, then verify the footer shows `Pursuing goal` AND a working line
  on the NEW account. Verify every time.
- **Never tight-loop your own context.** Wait between checks with a backgrounded
  poller that exits early on trouble; do not busy-poll in the foreground.
- **Keep going until codex's OWN goal is genuinely complete** (footer
  `Goal achieved` plus a real, evidenced final report) — not until the first green
  moment, a single passing check, or a commit.
- **Keep a short append-only worklog** of every check and every rotation, where
  the user wants it (a docs dir they name, or `/tmp` scratch). Learnings and
  rotations go in as they happen, not at the end.

## First move

1. Read `references/signals-and-runbook.md`.
2. Confirm prerequisites exist on the host: `codex`, `aim`, `tmux`.
3. Identify the target: the tmux session/pane (`tmux capture-pane -t <target> -p`)
   and the codex `<SESSION_ID>` (from the footer or `~/.codex/sessions/...`).
4. Capture the pane once and classify state: working / idle / rate-limited / done.
5. Note the active account and pool headroom: `aim status` (CODEX block) and
   `aim status --accounts`.
6. Start the worklog, then arm the first background poll cycle.

## Workflow

### 1. Establish baseline
Capture the pane, read the footer signals, record the active account and session
id, and confirm codex is actually working (not already idle/stuck). Start the
worklog with the target, session id, account, and the goal it is pursuing.

### 2. Watch on a cadence
Run a background poll (~15 min) that early-exits on a hard usage-limit, process
death, or stuck-reconnect, and otherwise emits one healthy tick. On each wake:
capture, judge, act if needed, append one worklog line, re-arm the next cycle.
Tighten the cadence only during an imminent-incident window. See the reference for
the exact signal strings and the no-tight-loop poll pattern.

### 3. Rotate + restart + resume (on a real limit or death)
Pick a healthy `ready` account with low 5h *and* weekly usage, `aim codex use
<label>`, verify `auth.json`. Kill the pane's codex child, relaunch
`codex resume <SESSION_ID>`, clear the resume-goal menu, and verify `Pursuing
goal` + a working line on the new account. Full step-by-step runbook is in the
reference.

### 4. Judge completion
Stand down only when codex declares the goal genuinely complete (`Goal achieved`
plus an evidenced final report). Carefully distinguish "done" from "idle/stalled"
(nudge/restart) and from "paused" (resume). When unsure, keep watching.

## Output expectations

- A short heartbeat to the user on each healthy tick, and a clear report on every
  rotation: what tripped, which account you moved to, and the evidence that work
  actually resumed.
- An append-only worklog capturing checks, learnings, and every rotation.
- A final stand-down message when the goal is genuinely complete — with the
  evidence (footer, commits, reviews) that it is real, not premature.

## Reference map

- `references/signals-and-runbook.md` — pane signal strings (working / idle / goal
  states / hard limit / transient / done), aim rotation facts, the exact
  kill→restart→resume→verify runbook, the no-tight-loop background poll pattern,
  the self-spawned-delegate caveat, and how to judge real completion.