Claude Code /goal vs Codex /goal

Both Claude Code and Codex have a /goal command that keeps the agent working across turns until a stated end state is reached, instead of stopping after one reply. The difference is who decides the work is done. In Claude Code, a separate small model checks your condition after every turn, so the agent that wrote the code isn't the one grading it. In Codex, the goal is a durable objective on the thread that Codex works toward until it's confident the stopping condition holds, with explicit pause, resume, and clear controls and a budget that can end the run.

Both are the simplest form of a loop: one objective, one check, repeat. We checked every detail below against first-party documentation on October 9, 2026.

Side by side#

	Claude Code /goal	Codex /goal
What it sets	A completion condition for the session	One durable objective for the thread
Who judges "done"	A small, fast model, after every turn	Codex, against the evidence in the thread
Commands	/goal <condition> sets it; /goal alone checks it; /goal clear removes it	/goal <objective>, /goal to view, /goal pause, /goal resume, /goal clear
Stops when	The condition is met, judged impossible, a turn fails on an error you must fix, or you clear it	Success, pause, clear, interruption, a budget limit, or a blocker that needs you
Pausing	Automatic after failures a retry would repeat, such as usage limits	Manual, with /goal pause and /goal resume
Across resumes	Restored when you resume the session	Belongs to the thread
Unattended runs	Doesn't change permission mode; run it in auto mode	Follows your approval and sandbox settings
Setup	Built in	Enable features.goals in config.toml if the command is missing

How Claude Code's /goal works#

You type a condition, such as "every test in test/auth passes and lint is clean." When a turn ends, a small, fast model reads the session and decides whether the condition holds. If not, its reason becomes guidance for the next turn and Claude keeps going without waiting for you. The goal ends in one of three ways: the evaluator confirms it (recorded as achieved), the evaluator judges it impossible (recorded as failed, with the reason), or a turn fails on an error that won't clear until you fix it (docs).

Two details matter in practice. A goal doesn't change your permission mode, so in a normal session Claude still stops to ask before commands your settings don't allow; use auto mode for runs you want to walk away from. And after a failure that a retry would only repeat, such as a rate limit or usage limit, the goal pauses with a notice that names the cause, then picks up again when a usage limit resets if the session is waiting to continue.

Anthropic's docs place /goal beside two neighbors. /loop starts the next turn when a time interval elapses rather than when the last turn ends, and a Stop hook lets your own script decide whether to continue. Pair them: Anthropic suggests combining /goal and /loop with dynamic workflows for repeatable triage and verification.

How Codex's /goal works#

In Codex, /goal gives a thread one durable objective. Codex inspects the code, runs commands, makes changes, tests the result, and keeps going until it reaches a stopping condition: success, a pause or clear from you, an interruption, a budget limit, or a blocker that needs your input. OpenAI says a goal can let Codex work independently for many hours, and suggests treating it as a background task you don't need to watch (Codex docs).

OpenAI's cookbook recommends a two-step habit: describe the work in plain language and ask Codex to draft the goal, then tighten the success condition, the evidence that proves it, the constraints, and when to stop as blocked before you activate it. Its template is desired end state, verified by specific evidence, while preserving constraints.

Writing a goal that works in both#

Whichever agent you use, the goal is a contract. Good ones share five parts:

1. One outcome. Not "improve the auth module" but "replace the session library with the v3 SDK."
2. Evidence a machine can check. A command that exits 0, a test file that passes, a benchmark under a threshold.
3. Where to look first. The files, docs, issue, or logs the agent should read before changing anything.
4. Constraints. What must not change: public APIs, test files, migrations already deployed.
5. When to give up. What counts as blocked, so the agent stops and reports instead of thrashing.

Pitfalls#

• Goals nobody can verify. "Make it faster" gives the evaluator nothing to check. Name the benchmark and the threshold.
• Passing by cheating. If tests can be edited, a determined agent may edit them. Say which files are off limits, and check the diff.
• Permission stalls. An unattended goal that hits an approval prompt just waits. Decide the permission mode before you leave.
• Cost. A goal that runs for hours spends tokens for hours. Set a budget where the tool supports one, and watch usage the first few times. Agentastic's Usage & Cost view shows both agents' usage from logs on your disk.
• Two goals, one checkout. Each goal needs its own session, and parallel goals need their own worktrees.

Run the same goal in both#

Because the commands share an idea, the same goal makes a clean head-to-head between agents. Start Claude Code and Codex from the same commit in separate worktrees, give each the same goal, and keep the diff that meets it with the fewest surprises. In Agentastic, each agent gets its own worktree and terminal or chat, and the diff viewer makes the comparison quick; see Claude Code vs Codex for how the agents differ beyond /goal.

Sources#

• Anthropic: Keep Claude working toward a goal, scheduled tasks and /loop, dynamic workflows, A harness for every task
• OpenAI: Follow a goal, Using goals in Codex
• Addy Osmani, Loop Engineering
• On this site: loop engineering, run multiple Claude Code agents in parallel, run Codex agents in parallel

Frequently asked questions#

What does /goal do in Claude Code?#

It sets a completion condition for the session. After every turn, a small, fast model checks whether the condition holds; if it doesn't, Claude starts another turn instead of handing control back. The goal clears when the condition is met, when the evaluator judges it impossible, or when a turn fails on an error you have to fix.

What does /goal do in Codex?#

It gives Codex one durable objective for the thread, so it keeps working across turns, sometimes for hours, until it is confident it has reached a verifiable stopping condition. You can check it with /goal and control it with /goal pause, /goal resume, and /goal clear. It also stops at a budget limit or a blocker that needs you.

How do I enable /goal in Codex?#

If /goal doesn't appear in Codex's slash command list, OpenAI's docs say to enable features.goals in config.toml. Claude Code's /goal is built in and needs no setting.

Can I pause a goal?#

In Codex, yes: /goal pause and /goal resume. Claude Code doesn't document a manual pause; it pauses on its own after failures a retry would only repeat, such as a usage limit, and resumes when the limit resets if the session is set to continue. In both tools, clearing the goal stops it.

What is the difference between /goal and /loop in Claude Code?#

/loop re-runs a prompt on a time interval while the session is open, which suits polling a deploy or babysitting pull requests. /goal starts the next turn as soon as the previous one ends and stops when a model confirms your condition, which suits finishing one piece of work.

Can I run several goals at once?#

One goal is active per Claude Code session and per Codex thread. To run several, give each its own session and its own git worktree so their changes can't collide. Agentastic starts each agent in a separate worktree, so you can run Claude Code and Codex on the same goal side by side.