Add time-based scheduling for commands/tasks (delay, interval, and conditional polling)

[bhack]

What feature would you like to see?

Problem

Codex CLI supports interactive execution, but there is no first-class way to schedule a task to run later or repeatedly (e.g., “check logs every 10 minutes”, “run tests nightly”, “poll until a service is healthy, then proceed”). Today users must rely on external schedulers (cron/systemd/Task Scheduler), which loses Codex context/session semantics and makes logs/results harder to manage inside Codex.

Requested capability

Add a scheduling primitive to run commands/prompts:

• One-shot delayed execution (“run once at/after a time”)
• Fixed-interval execution (“run every N minutes”)
• Conditional polling (“poll until condition is met or timeout”)

Examples (illustrative)

• codex schedule --every 10m --name check-logs -- <command or prompt>
• codex schedule --at "2025-12-20 09:00" --name daily-tests -- <command or prompt>
• codex schedule --until "<condition>" --poll 30s --timeout 15m --name wait-ready -- <command or prompt>

Desired behavior / acceptance criteria

1. Support one-shot schedules (--at, --in) and recurring schedules (--every).
2. Schedules are manageable: list, inspect, pause/resume, and remove (e.g., codex schedule ls|show|pause|resume|rm).
3. Each run produces a clear execution record: start/end timestamps, exit status, stdout/stderr (or a pointer to stored output).
4. Define a clear and predictable concurrency/conflict model (see below).
5. Define persistence model explicitly:
   • Preferably schedules persist across terminal restarts (or clearly document if they do not).
6. Provide sensible guardrails:
   • prevent runaway loops
   • rate limits / minimum interval
   • optional max-runs / stop conditions

Concurrency / conflict behavior

When a scheduled run triggers while another task is running, define how Codex behaves:

• Default: scheduled runs are queued and execute sequentially (no interleaving output).
• Configurable (optional):
  • --concurrency=queue (default)
  • --concurrency=parallel (run in parallel, separate logs/output)
  • --concurrency=skip (skip this occurrence if Codex is busy)
• Guardrails (optional):
  • --max-queue-depth N or --drop-policy=drop-oldest|drop-newest
  • --misfire=run-once|skip if Codex was offline/busy for a long time

Why this matters

Time-based automation is a common workflow (log monitoring, smoke tests, periodic checks). Providing it natively in Codex makes the tool more useful without requiring external cron wrappers and fragmented logging.

Related (adjacent, not the same)

Task/command queueing is related but does not address time-based triggers: #5051, #5123.

Additional information

No response