Add a /loop recurring prompt command to the Codex TUI

Summary

Add a /loop <interval Xm> <message> slash command that queues a user message on a repeating minute-based interval.

Examples:

/loop 3m continue
/loop 5m summarize progress

Expected behavior

Parse strict minute syntax only: /loop <Xm> <message>.
Queue the message every X minutes.
If a turn is already running, queue the next loop message instead of interrupting the active turn.
Re-running /loop should replace the previous schedule.
If a loop-triggered turn determines the work is already fully complete, the loop should remove itself and drop future queued loop messages.

Scope

The behavior should be implemented consistently in both codex-rs/tui and codex-rs/tui_app_server.

Implementation status

A working implementation is available here:

Validated locally with:

cargo check -p codex-tui -p codex-tui-app-server

Related issues / duplicates

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

Persistent Callback orchestration/Loop #14110

Powered by Codex Action

Implementation is ready on my fork, but GitHub is denying CreatePullRequest for this account when targeting openai/codex.

Prepared branch:

Fork: cruzlauroiii/codex-fork
Branch: cruzlauroiii/loop-command-auto-cancel
Commit: 8b8793ef9f156fb138fedcc13a688c5c1e729f3a

Compare URL:
https://github.com/openai/codex/compare/main...cruzlauroiii:cruzlauroiii/loop-command-auto-cancel?expand=1

Validation completed locally:

cargo check -p codex-tui -p codex-tui-app-server

This implements:

/loop <interval Xm> <message> in both TUI frontends
queued loop turns without interrupting an active turn
automatic loop removal when a loop-triggered response determines the work is already complete

I could not open an upstream PR from this account due to GitHub permission restrictions, but the implementation is now available as a fork PR here:

Fork PR: https://github.com/cruzlauroiii/codex-fork/pull/1
Branch: cruzlauroiii/loop-command-auto-cancel
Commit: 8b8793ef9f156fb138fedcc13a688c5c1e729f3a

The fork PR body links back to this issue for context.

this would be amazing. Claude code having such a feature is currently the only reason for me keeping my claude subscription without fully switching to codex. My use case is monitoring and automatically recovering long running workflows like ML training runs.

Highly wanted, please!

we need the /loop feature same as claude code.

Please add this feature. This is the only feature for which I am still in claude code.

Please add this feature so I can switch from Claude Code to Codex.

We need this feature.

+1

I need the /loop 10m repeated task command too

These three (#15679, #14110, #8317) are really one feature at three altitudes: a
prompt loop in the TUI, a persistent cross-turn orchestrator, and a scheduler
CLI. They'll fight each other unless they sit on a single primitive. The design
pattern that held up in my implementation:

One primitive: a named, persisted, per-thread recurring job. Named (not a
single global schedule) is what makes "re-running replaces it" well-defined and
lets several watchers coexist. Persist it in a small store keyed by thread so it
survives a restart — that one choice covers #8317's persistence requirement and
#14110's "alive between turns" at the same time.

A few decisions that mattered more than expected:

Never interrupt an active turn. A tick that lands mid-turn (or during
review mode / a side conversation) marks the job pending and retries at the
next safe point — skip-if-busy, no backlog. That single rule is most of
Add a /loop recurring prompt command to the Codex TUI #15679's "queue vs. interrupt" question.
Give the job a goal and a terminal status (progress / blocked /
done). In background/owner mode a done tick lets the job wind itself down;
in the main-turn path the runtime instead instructs the model to call the
manage tool to remove it. The same terminal-state machinery is the natural
place for a max-runs guardrail (I don't have a run counter yet).
Clamp the interval with a hard min and max (mine is 30s–24h). Cheapest
possible anti-runaway guard.
Two tick modes. Either inject a prompt into the main turn, or hand the
tick to a background owner that reports status without consuming the main
turn — that second mode is what Persistent Callback orchestration/Loop #14110 is actually after. A lightweight
status-only tick (no LLM call: it just updates state and reschedules) covers
heartbeat / "still watching" checks.
Expose it as both a slash command and an agent-callable tool, so the model
can set up its own follow-up check and later stop it. That's what makes
"supervise a long-running job, wind it down when done" work end to end.

Scope-wise it lands where #15679 already points: the TUI, a small state/storage
layer, and the tool surface — not the TUI alone. What I run is a slash command
plus a dynamic tool rather than a separate scheduler CLI, but the underlying job
model is the same one #8317 would need. Happy to go deeper on any of these
tradeoffs.

+1

A concrete VS Code Remote / CLI use case for this feature:

I was running three local 4-hour network probe variants and asked Codex to check their progress every 30 minutes, diagnose failures, make narrowly scoped test-harness fixes, rerun targeted validation, and stop the loop after all probes completed.

The current workarounds do not preserve the workflow:

An external OS cron job can inspect logs, but it cannot resume the same Codex thread with its existing context or continue diagnosis and repair.
A durable/long-running goal does not provide a fixed cadence, and in this case the goal later disappeared while the underlying processes kept running.
The VS Code extension currently has no Scheduled management interface.

A command such as:

/loop 30m Check the three probe runs, report anomalies, fix test-harness issues only, and stop when all runs finish.

would fit well if it:

works through both the TUI and app-server/IDE-extension surfaces;
resumes or queues work in the same thread without interrupting an active turn;
persists across extension/terminal restarts, or clearly exposes its lifetime;
supports automatic cancellation when the task reaches a terminal condition; and
keeps an inspectable run history so users can verify that scheduled checks actually occurred.

This is not only a reminder use case: preserving thread context is what allows the scheduled check to safely distinguish product code from test-only code and continue a constrained debugging workflow.

We've added the /goal command, which can be used for implementing looping behaviors. We're unlikely to add /loop since it would be largely duplicative.

@etraut-openai

@etraut-openai Hey Eric, providing one feedback here w.r.t to the /loop feature: for me in a longer run (10hrs+) with multi-agents sometimes I often want to inspect the status or the execution/experiment or add a timed event mid-flight. These can be best described using a /loop command and often they are not known in advance when describing with /goal, therefore I think loop is definitely having its unique usages.

@etraut-openai

@etraut-openai I believe /goal for looping behaviors is currently broken / not working as designed. Please see: #40170

Navigation Menu

Repository navigation

Add a /loop recurring prompt command to the Codex TUI #15679

Summary

Expected behavior

Scope

Implementation status

Related issues / duplicates

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Add a /loop recurring prompt command to the Codex TUI #15679

Description

Summary

Expected behavior

Scope

Implementation status

Related issues / duplicates

Activity

github-actions commented on Mar 24, 2026

cruzlauroiii commented on Mar 24, 2026

cruzlauroiii commented on Mar 24, 2026

nepfaff commented on Apr 13, 2026

jianshuod commented on Apr 28, 2026

hijkzzz commented on Apr 28, 2026

aislam-nv commented on May 2, 2026

YqGe585 commented on May 26, 2026

mlgrozev commented on May 26, 2026

lukehansen commented on Jun 5, 2026

snailwei commented on Jun 18, 2026

DioNanos commented on Jul 8, 2026

sophiapeng90 commented on Jul 12, 2026

18954154969 commented on Jul 13, 2026

etraut-openai commented on Jul 22, 2026

TH3CHARLie commented on Aug 6, 2026

banagale commented on Aug 23, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions