Add a /loop recurring prompt command to the Codex TUI

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

• #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
#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 #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:

1. works through both the TUI and app-server/IDE-extension surfaces;
2. resumes or queues work in the same thread without interrupting an active turn;
3. persists across extension/terminal restarts, or clearly exposes its lifetime;
4. supports automatic cancellation when the task reaches a terminal condition; and
5. 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.