›_ Codex Issues
Codex Issues / #8317

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

Open 💬 6 comments Opened Dec 19, 2025 by 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).
  1. 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_

View original on GitHub ↗

6 Comments

dangreenlee · 5 months ago

This is close to what I need.

My main use case is in-chat, one-time scheduling:

  • "check again in 30 min"
  • run once (not recurring)
  • stay in the same thread and post results there

Could this chat/app flow be included in scope, or should I open a separate issue and link it here?

wakamex · 5 months ago

I've been using a minimal /loop implementation and it's been working well for me https://github.com/openai/codex/compare/main...wakamex:codex:main

cruzlauroiii · 5 months ago

This overlaps with #15679, which tracks a working in-chat /loop <interval Xm> <message> implementation.

Links:

#8317 is broader and covers one-shot scheduling, intervals, persistence, and management commands. #15679 is the narrower recurring same-thread loop command that is already implemented and ready for review.

18954154969 · 1 month ago

Adding another concrete use case for this request.

I'm using Codex CLI 0.144.1 in a Linux, CLI-only development environment. The current official Scheduled Tasks documentation says that scheduled tasks must be created and managed through ChatGPT web or the desktop app; the CLI does not provide the Scheduled management interface.

Using external cron or a systemd timer to invoke codex exec is possible, but it loses important Codex-native semantics:

  • creating and managing schedules from the CLI
  • resuming or posting results into the same thread
  • choosing an isolated worktree for each run
  • viewing run history and status in one place
  • pausing, resuming, and removing schedules consistently across Codex surfaces

It would be valuable for the CLI to have first-class parity with Scheduled Tasks, especially for remote Linux, SSH, headless, and server-side development workflows. Even an initial codex schedule create|list|pause|resume|delete interface backed by the same scheduling model would remove the need for fragile external wrappers.

dolzenko · 1 month ago
This is close to what I need. My main use case is in-chat, one-time scheduling: "check again in 30 min" run once (not recurring) * stay in the same thread and post results there Could this chat/app flow be included in scope, or should I open a separate issue and link it here?

Can't you achieve that with !? E.g.
! sleep 1800 # wait for 30 min

and immediately after

> do things
• Queued follow-up inputs
  ↳ do things
bhack · 1 month ago

Something could be achieved with customized sleep aware skills. But honestly a more off the shelf experience with triggers that can reactivate the agent it would a lot better.