How to Run Loops in Codex CLI (There Is No /loop)

Codex CLI has no /loop. That is the whole mix-up. People learn loop engineering in Claude Code, type the same slash command into Codex, and assume the product is missing a feature. It is not. Codex splits the job into two primitives Claude folds into one interval picker: /goal keeps a thread working until a verifiable end state, and Automations (or a shell loop around codex exec) fire the work again on a schedule.

This guide is the Codex sibling of explainx.ai's loop-engineering hub. If you still need the concept, start at what loop engineering is. If you already live in Claude Code, skip to the mapping table — then paste the starter /goal below.

TL;DR

Does Codex have /loop?

No. Codex CLI's slash-command list includes /goal, /compact, /plan — not /loop. Official docs never describe a Claude-style interval command. If a blog, gist, or model completion told you to type /loop 30m … in Codex, that recipe is for a different agent harness.

Claude Code's /loop is a timer: re-run this prompt every N minutes while the session stays open. Codex's /goal is a finish line: keep this thread working until this evidence is true. Same agent loop discipline — trigger, goal, actions, verification, memory — different product surface. Browse ready-made recipes on explainx.ai/loops; this post is how you actually run one inside Codex.

Three loops people collapse into one word

OpenAI itself unrolled the inner coding-agent cycle in Unrolling the Codex agent loop: the Responses API turn, tool calls, and a compact endpoint that summarizes history when the window fills. That loop is always on. It is not something you type.

What you author sits one layer up:

Loop engineering is designing those outer two layers so the inner one is a subroutine, not a conversation you babysit. OpenAI's follow-goals docs put it in one sentence: use /goal when you want Codex to keep working toward one durable objective instead of stopping after one normal turn.

The cookbook draws the same contrast:

Prompt: ask → work → result → wait

Goal: work → check → continue or complete

Continuation is event-driven when the thread is idle. After a turn finishes, Codex inspects current evidence. If the goal is still open, still in budget, and not paused, it continues from the latest state — you do not type "keep going."

Enable /goal (CLI 0.128.0+)

Goals shipped in Codex CLI 0.128.0. Confirm you are at least that new:

codex --version

If /goal is missing from the slash-command list, enable the feature flag and restart the session:

# ~/.codex/config.toml
[features]
goals = true

Or from the CLI:

codex features enable goals

You can also ask Codex to run that enable command for you. Some builds later flipped goals on by default; the flag is still the documented fallback when the command does not appear. After toggling config, close and reopen the TUI — a live session will not pick up the change.

Lifecycle, from the CLI reference and cookbook:

/goal <objective>     Set or replace the goal
/goal                 View current goal and status
/goal edit            Revise the objective
/goal pause           Suspend continuation; keep audit context
/goal resume          Continue from preserved state
/goal clear           Remove the goal; back to single-turn prompts

Objectives must be non-empty and at most 4,000 characters. Put a long spec in a file (PLAN.md, an issue, a test command) and point the goal at that file.

Copy-paste: set a goal that can actually stop

OpenAI's official starter:

/goal Complete [objective] without stopping until [verifiable end state].

Fill both brackets. "Complete the refactor" is a prompt. "Complete the refactor until pnpm test is green and auth/ has no remaining express imports" is a goal.

A stronger contract, from the cookbook pattern:

/goal Reduce p95 checkout latency below 120 ms, verified by the checkout
benchmark, while keeping the correctness suite green. Use only the checkout
service, benchmark fixtures, and related tests. Between iterations, record
what changed, what the benchmark showed, and the next best experiment.
If the benchmark cannot run or no valid paths remain, stop with attempted
paths, evidence, the blocker, and the next input needed.

Migration shape from follow-goals:

/goal Migrate this project from [legacy stack] to [target stack]. Keep
screens visually identical; verify with Playwright. Stop when the new path
passes contract tests and the legacy path still has a rollback.

Eval / prompt-tuning shape:

/goal Optimize the prompts in [path] until the eval suite reaches [target
score]. After each change, run [eval command], inspect failing cases, and
keep edits minimal. Stop when the target is met or further changes would
need product or policy guidance.

While it runs: type /goal for status. Ask for compact progress reports — current checkpoint, what was verified, what remains, whether it is blocked. If status goes vague, tighten the goal; do not pile on one-off "also do this" messages.

When it should stop: OpenAI is explicit that Codex stops when it is confident the stopping condition is met. No checkable evidence means no honest stop — the thread becomes a paid "keep going" loop. Pair that with a token or wall-clock budget so a stuck goal cannot spend overnight.

Recurring work: Automations, not /loop

/goal is one objective on one thread. It is not "every night at 2am." For recurrence, pick one of two outer loops.

Codex app Automations (scheduled tasks)

The Codex / ChatGPT app has scheduled tasks (docs still use the older "Automations" anchors). Official CLI docs are blunt: Codex CLI does not provide the Scheduled management interface. Create and manage the cadence in the app; use the CLI to draft and test the prompt first.

Use Automations when you want:

• a calendar or interval trigger (nightly triage, hourly PR babysit, weekly report)
• a standalone run that starts a new chat each time, or a thread schedule that returns to the same chat's context
• git worktrees so overnight edits stay off your dirty working tree
• skills / plugins in the scheduled prompt ($skill-name in the desktop app)

Constraints that actually bite: keep the machine on and the app running for local project files; web scheduled tasks cannot see a folder on disk. Scheduled runs use your default sandbox unattended — start workspace-write, not full access. Test the prompt in a normal chat before you put it on a clock.

Example ask inside a Codex chat:

Schedule a standalone nightly task at 02:00 that: pulls main, runs the
flaky-test suite, opens a draft PR only if it finds a failing test with a
reproducer, and otherwise reports "queue empty." Stop and ping me if git
push would require --force or if tests cannot run.

Minute-level schedules inside an existing thread are the closest Codex analogue to Claude's /loop 5m … — still an app feature, not a CLI slash command.

Wrap codex exec in a shell or cron loop

codex exec (short: codex e) is the non-interactive, CI-shaped entry point. Wrap it when each cycle should be a fresh process: GitHub Actions, a systemd timer, a cron line on a box that is already a runner.

#!/usr/bin/env bash
set -euo pipefail
# Recurring outer loop. Inner stop still belongs in the prompt.
codex exec "Triage new issues labeled 'bug' from the last 6 hours.
For each: reproduce, or record why reproduction failed.
Open a draft PR only when a test proves the fix.
Stop this run when the queue is empty or after 8 issues.
Do not push to main."

Cron:

0 2 * * * cd /path/to/repo && /path/to/nightly-codex.sh >> /var/log/codex-nightly.log 2>&1

Hard-stop the outer loop too: max iterations, a timeout, and a dollar/token ceiling. A cron that calls codex exec with "keep going" and no queue-empty check is how overnight bills happen. The loop-engineering hub treats those three stops as non-optional; they apply here.

Do not emulate /loop by putting while true; do codex exec "keep going"; done around an open-ended prompt. That is the inner harness with the finish line ripped out.

Long sessions: compact first, 1M context second

A /goal that runs for hours fills the window with tool output. First lever: /compact (and Codex's auto-compact) so the thread keeps the objective without shipping the entire grep history every turn. That is the compact endpoint from the inner-loop write-up, exposed as a slash command.

Second lever, only when compact is not enough: enable the 1M-token context window on GPT-5.6 Sol. A larger window is not free — more tokens per request, slower turns, and subscription plans have reported a lower effective cap than the config value. Use it for multi-hour investigations; leave the tuned default for a two-file fix.

What this means for what you build or pay

The myth is expensive in two directions.

Wrong primitive, wasted turns. Typing /loop into Codex does nothing useful. Pasting "keep going" after every Codex turn is the bill you pay for not using /goal. OpenAI's cookbook is written for exactly that failure mode: you already know you were going to say "run the benchmark again" — put it in the goal once.

Right primitive, unbounded spend. A /goal can run for hours. Automations multiply that by a cadence. codex exec in cron multiplies it by every box that has credentials. Price the loop, not the first prompt: model, reasoning effort, context window, and how often the outer trigger fires. A nightly codex exec on a small model with a queue-empty stop is a different product than a Sol Extended /goal on a 1M window with "make the architecture nice."

What to build. Put the procedure in a skill; put the finish line in /goal; put the clock in Automations or cron. That is the same conversion as turning a skill into a loop, mapped onto Codex's actual commands. If you are embedding Codex rather than sitting in the TUI, the same split shows up as codex exec vs the persistent Codex harness.

What not to pay for. Unattended danger-full-access, goals without a verification command, and schedules that start a new 1M-context thread when a 30-second pnpm test would have been the check.

Same loop, four harnesses

The vocabulary is shared. The slash commands are not interchangeable.

Honest limits

• /goal is not a scheduler. Closing the question "when does this run again?" still requires the app or your own cron.
• CLI has no Scheduled inbox. You will not get the app's Active / Paused / unread-runs UI in the TUI.
• Local Automations need the machine. Laptop lid closed, project path missing, or sandbox still read-only — the run fails unattended.
• Completion is evidence-based, not vibe-based. If "done" cannot be a command, a benchmark, or an artifact, /goal will either stop too early or not stop.
• The model can be confident and wrong. Keep tests or Playwright in the goal; do not treat "Codex said it finished" as the verification step.
• 4,000-character cap on the goal string. Long runbooks live in files.

Related reading

• Loop engineering: coding-agent loops that run while you sleep
• What is loop engineering?
• How to run loops in Claude Code · Cursor · GitHub Copilot
• Enable a 1M-token context window in Codex CLI
• Turn agent skills into loops
• Browse explainx.ai loops
• Follow a goal · Using goals in Codex (cookbook) · CLI reference (/goal) · Unrolling the Codex agent loop · Scheduled tasks / Automations

Codex CLI version numbers, /goal feature-flag defaults, Automations UI, and context-window config are accurate as of August 20, 2026. Confirm codex --version and the current slash-command list on your install before you depend on a flag that may already be default-on.