Skip to content

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

Open
Open
Add time-based scheduling for commands/tasks (delay, interval, and conditional polling)#8317
Labels
agentIssues related to the core agent loopenhancementNew feature or request

Description

@bhack
bhack
opened on Dec 19, 2025

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

Activity

  1. bhack
    added
    enhancementNew feature or request
    on Dec 19, 2025
  2. github-actions
    added
    CLIIssues related to the Codex CLI
    on Dec 19, 2025

  3. dangreenlee commented on Mar 4, 2026

    @dangreenlee
    dangreenlee
    on Mar 4, 2026

    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?

  4. wakamex commented on Mar 10, 2026

    @wakamex
    wakamex
    on Mar 10, 2026

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

  5. cruzlauroiii commented on Mar 24, 2026

    @cruzlauroiii
    cruzlauroiii
    on Mar 24, 2026

    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.

  6. etraut-openai
    added
    agentIssues related to the core agent loop
    and removed
    CLIIssues related to the Codex CLI
    on Apr 2, 2026
  7. jeremyphilemon
    added a commit that references this issue on May 25, 2026

    feat: port curator agent to Codex and OpenCode

    89cfc7f

  8. 18954154969 commented on Jul 13, 2026

    @18954154969
    18954154969
    on Jul 13, 2026 – with ChatGPT Codex Connector

    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.

  9. dolzenko commented on Jul 20, 2026

    @dolzenko
    dolzenko
    on Jul 20, 2026

    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

  10. bhack commented on Jul 20, 2026

    @bhack
    bhack
    on Jul 20, 2026
    Author

    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.

  11. KlausMeng commented on Sep 6, 2026

    @KlausMeng
    KlausMeng
    on Sep 6, 2026

    It would be great to see if this can also be implemented in VSCode Codex plugin.

  12. cderek-gu commented on Sep 9, 2026

    @cderek-gu
    cderek-gu
    on Sep 9, 2026 – with ChatGPT Codex Connector

    Concrete reliability failure on codex-cli 0.153.4 (Linux/WSL):

    I asked an interactive Codex session to wait one hour and then continue a multi-step workflow. The wait itself completed, but the following agent turn was marked turn_aborted. No durable scheduler, supervisor, or automatic session re-entry resumed the remaining work. A saved goal/state file also did not wake the agent. The downstream tasks were therefore never executed, with no useful failure notification to the user.

    This is more than a convenience gap. The current interaction makes a delayed instruction look as though it will continue reliably, while a CLI turn is not a persistent scheduled job. Losing an entire unattended work window because of that distinction is unacceptable.

    Please add first-class CLI support for:

    • one-shot delayed continuation and recurring tasks;
    • persistence across turn, terminal, client, and connection interruptions;
    • automatic re-entry/resume using saved session context;
    • an explicit terminal reason when a delayed task cannot resume;
    • visible status, execution history, failure notification, retry policy, and missed-run handling;
    • clear UI copy that an ordinary agent wait is not a durable timer.

    This reliability gap is serious enough that I am switching to Claude Code for unattended workflows. Codex should not require the desktop app or web UI for a basic durable timer/resume primitive.

  13. AvatarGanymede commented on Sep 24, 2026

    @AvatarGanymede
    AvatarGanymede
    on Sep 24, 2026

    Adding a concrete CLI-orchestrator lifecycle case that is not fully covered by the current acceptance criteria.

    An external worker runs codex exec --json and consumes its JSONL events. During a task, Codex needed to recheck an external lock every 10 minutes. Because the CLI has no scheduling primitive, the agent created a PowerShell polling script and a Windows Task Scheduler entry, then emitted turn.completed.

    That workaround has no native relationship to the Codex session:

    • the scheduled job is not discoverable through the CLI or App Server as work belonging to the thread;
    • completion of the polling job does not automatically resume the original session;
    • the worker sees turn.completed and can incorrectly treat the overall workflow as complete;
    • reliably inferring ownership from process names, scripts, or OS scheduler metadata is not possible across platforms.

    In addition to create/list/pause/resume/delete, a native scheduler should expose enough lifecycle state for orchestrators:

    1. Bind every schedule to a stable schedule ID and target thread/session ID.
    2. Support a one-shot same-thread wakeup such as "resume this session in 10 minutes with this prompt", without keeping codex exec alive.
    3. Expose pending, running, completed, cancelled, and failed schedules through both CLI and App Server.
    4. Emit structured schedule lifecycle events in JSONL.
    5. Distinguish "the current turn completed" from "the thread has no pending scheduled work". A queryable pending-work field or an explicit quiescent event would let external workers decide when the overall workflow is actually finished.
    6. Persist the schedule across CLI process exit and define restart, missed-run, overlap, and exactly-once behavior.

    This would avoid platform-specific cron/Task Scheduler scripts and make delayed continuation safe for headless CLI integrations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    agentIssues related to the core agent loopenhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions