I have started treating AI coding agents less like chat windows and more like workers with contracts. The difference is not the model. The difference is whether the agent knows what to keep doing, how to prove progress, and when to stop.
That is where /loop and /goal matter.
Claude Code now exposes both ideas directly: /goal for a completion condition, and /loop for repeated prompts while a session stays open. OpenAI Codex has /goal as a documented command, and OpenAI also documents eval-driven improvement loops as a workflow. The important detail: I would not describe OpenAI Codex as having the same official /loop slash command unless that appears in your installed command list. In the current docs I checked, /goal is official; “loop” is the pattern.
That distinction matters because these tools look similar from the outside, but I use them for different jobs.
Quick answer
Use /goal when the agent should pursue one durable outcome until a clear condition is true.
Use /loop when the agent should repeat a prompt on an interval or self-paced rhythm while the session remains open.
Use an eval-driven loop when the output can be scored and improved repeatedly: code quality, visual quality, performance, SEO, migrations, tests, or any task where each pass can be measured.
The practical rule is simple: a goal needs a finish line; a loop needs a cadence; both need verification.
What Claude Code /goal does
Claude’s command reference describes /goal [condition|clear] as a way to set a condition so Claude keeps working across turns until that condition is met. The hook docs add a useful implementation detail: /goal behaves like a built-in shortcut for a session-scoped stop condition.
In plain English, /goal tells Claude:
That is powerful, but only if the condition is concrete.
Weak:
/goal Make the app betterUseful:
/goal Fix the checkout bug, keep all existing payment behavior intact, and stop only when pnpm test, pnpm build, and the Playwright checkout path all pass.The second version gives Claude a target, boundaries, and proof. It can decide the path, but not redefine success halfway through.
I use /goal for work like:
The moment a task has multiple unrelated outcomes, I do not use one big goal. I split it. One goal per outcome is cleaner and easier to trust.
What Claude Code /loop does
Claude’s command reference lists /loop [interval] [prompt] as a bundled skill. It runs a prompt repeatedly while the session is open. You can give it an interval, let Claude self-pace, or omit the prompt and let it use a configured maintenance prompt where available.
That makes /loop feel more operational than /goal.
Examples:
/loop 5m check if the Vercel preview deployment is ready, then verify /blog and /api/health/loop take the next unchecked item in PRODUCTION_READINESS.md, fix it, run the relevant test, then update the checklist/loop every 10m check CI, summarize failures, and stop escalating only after the latest run is greenThe best use case is repeated checking or repeated small work units. In my hybrid AI code review loop→, the useful pattern was not “write forever.” It was: take one checklist item, implement it, ask another model to review, run the build, tick the box, repeat.
That is what makes /loop dangerous if you write a lazy prompt. If the prompt does not say what to verify, the agent can keep doing plausible work that nobody should trust.
What OpenAI Codex /goal does
OpenAI documents /goal for Codex in both the app and CLI. The Codex guide frames it as a durable objective for long-running work, especially when the task has a clear success condition and validation loop.
The Codex CLI command reference lists /goal as the command to set, pause, resume, view, or clear a task goal. The app docs say the same idea in product terms: a goal is persistent, visible, and can be paused or resumed.
A good Codex goal looks almost identical to a good Claude goal:
/goal Complete the Next.js 16 migration without changing public routes. Stop only when pnpm build passes, the homepage loads, /blog loads, and the changed routes return 200.For Codex, I like goals that name:
OpenAI’s own guidance for difficult problems is close to how I already work: give Codex an evaluation system, make focused improvements, re-run the score, inspect artifacts, and keep going until the score is good enough.
That is the heart of agentic work. Not autonomy for its own sake. Autonomy tied to measurement.
Does OpenAI have /loop?
This is where people can get sloppy with the wording.
Claude Code has a documented /loop command. OpenAI Codex has documented loop-style workflows: eval loops, repair loops, goal mode with validation, hooks, and automations. But in the current Codex slash command reference I checked, I found /goal, /plan, /review, /status, /mcp, and many others, not an official /loop command equivalent to Claude’s.
So my wording is:
That is not a weakness. It just changes how I set it up. In Codex, I usually express the loop inside the goal or prompt:
/goal Improve this component until the visual regression score is above 95%. Make one focused change at a time, run the screenshot comparison after each change, keep a score log, and stop when the target holds twice in a row.That gives Codex the same operating rhythm without pretending there is a separate /loop slash command.
My practical setup
For serious work I use a five-layer pattern.
1. A written target
I start with a short plan or checklist. It can be `PLAN.md`, `PRODUCTION_READINESS.md`, a GitHub issue, or a plain prompt. The format matters less than the checkability.
A weak task says “improve the article system.”
A strong task says “prevent publish when external URLs return 404, soft 404, wrong content-type, or redirect to the wrong target; keep draft saves allowed; prove with build and a focused validation case.”
That is the kind of instruction an agent can keep acting on.
2. One owner model
Pick who is driving. Claude may be the implementer. Codex may be the implementer. Do not let both edit the same files at the same time unless you have worktrees or a strict handoff. Autonomy without ownership becomes merge conflict theater.
3. A second opinion
For higher-risk work I still like model-to-model review. I have written about my AI peer-review bridge→ because it catches different failure modes than a single model checking itself.
The reviewer can be read-only. It does not need write access to be useful. It needs the diff, the goal, the risky files, and permission to say “this is wrong.”
4. A hard validator
Tests beat confidence. Builds beat summaries. Browser screenshots beat “it should render.” Logs beat vibes.
For web work, that usually means:
pnpm build
pnpm lint
pnpm testplus route checks, screenshots, or Playwright flows when the task is user-facing.
For content workflows, my preference is URL QA before publish: not only “did the link return 200,” but “did it reach the page the article claimed?” That is the same principle. The validator should verify the thing the reader actually experiences.
5. A stop rule
This is the part people skip.
A loop without a stop rule becomes expensive. A goal without a stop rule becomes vague. A stop rule should be boring and literal:
That last line is important. Good agents do not hide uncertainty. They surface it.
When I use each one
| Situation | Best tool | Why |
|---|---|---|
| --- | ---: | --- |
| One large task with a clear definition of done | /goal | The agent can keep moving toward a durable end state |
| Checking deployment status every few minutes | Claude /loop | The same check needs to run repeatedly |
| Improving a generated artifact against a score | Eval loop | The score tells the agent whether the last pass improved anything |
| Cleaning a checklist item by item | /loop or /goal | Use /loop for repeated items, /goal for the final outcome |
| Research with uncertain direction | Normal prompt or plan mode | Do not start autonomy before the target is clear |
| Sensitive production action | Human approval gate | Agents can prepare the action, but should not silently execute it |
Copy-paste prompts
Claude Code /goal
/goal Finish this bug fix without changing unrelated behavior. First read AGENTS.md and the relevant route/component files. Make small commits in logic only, run pnpm build and the focused regression path, and stop only when the original bug no longer reproduces and all verification passes.Claude Code /loop
/loop take the next unchecked item in TODO.md, inspect the real files first, make one focused fix, run the relevant validation command, update the checkbox only after verification, and report any blocker instead of skipping itOpenAI Codex /goal
/goal Complete the migration described in PLAN.md. Preserve public behavior, keep unrelated files unchanged, run the listed validation commands after each milestone, keep a short progress log, and stop only when every milestone is complete and the final build passes.Codex eval-driven loop prompt
I want this as an eval-driven improvement loop. Find or create the command that scores the output. Make one focused improvement at a time, re-run the score after each change, inspect any generated artifact directly, log score changes, and keep iterating until the target score is reached twice in a row. If the score stops improving, explain the bottleneck and stop.Common mistakes
The first mistake is using /goal as a motivational sentence. “Make this production ready” is not a goal. It is a mood.
The second mistake is using /loop without a validator. If every iteration ends with an unchecked claim, the loop is just repetition.
The third mistake is bundling unrelated work. “Fix auth, redesign the dashboard, update pricing, and clean SEO” should be four tasks, not one heroic autonomous run.
The fourth mistake is giving the agent write access before it understands the repo rules. In my own projects, I want agents to read `AGENTS.md`, respect deploy rules, avoid secrets, and verify before claiming success. The control layer around the model matters as much as the model. That is why I keep coming back to MCP developer workflows→: tools, permissions, evidence, and replayable actions are what turn a clever chat into an operational system.
The real point
The interesting thing about /loop and /goal is not the slash command syntax. The interesting thing is the shift in responsibility.
A normal prompt says: answer me.
A goal says: finish this, and know what finished means.
A loop says: keep checking or improving until the condition changes.
That is how I want AI coding agents to work. Not as magic. Not as unsupervised chaos. As workers with a contract, a validator, and a clean stop rule.
If you use Claude Code, /loop is the fastest way to turn a repeated operational check into something the agent can handle while you keep working. /goal is the better tool when the work has one durable end state.
If you use OpenAI Codex, /goal gives you the durable objective, and the loop belongs in the validation design: tests, evals, artifacts, hooks, progress logs, and a stop condition the agent cannot quietly redefine.
That is the pattern I trust: not “let the AI run,” but “let the AI run inside a system that can tell it no.”
