Codex Goals: The Autonomous Coding Loop Claude Code Doesn't Have

Codex's experimental Goals feature might have Claude Code beat for autonomous, long-running coding tasks. It's a built-in Ralph loop — one /goal slash command, no third-party orchestration layers, no scaffolding. You give it an objective and clear completion criteria, and it works for potentially hours without you needing to intervene.

I just used it to build a 2D arcade survival game called Rift Salvage from scratch — original sprites, working combat system, boss phase, the whole thing — across two goal runs totaling about 45 minutes. Here's exactly how Goals works, how to enable it, and the demo so you can see what kind of compounding work this thing can crank through hands-off.

What Is the Codex Goals Feature?

Goals is an experimental Codex feature that turns a single slash command into a long-running autonomous coding loop. It's available in both the Codex desktop app and the Codex CLI. Under the hood, it's a more sophisticated version of what the dev community calls a Ralph loop — but bundled into the platform instead of stitched together with bash.

The big-picture idea: you give Codex an objective and a quantifiable definition of "done." Codex then loops on its own, reading and updating internal state files, executing turns, checking progress, and self-verifying until either the goal is complete or it bumps up against a budget limit. No babysitting, no manual continue prompts.

If you've used GSD or Superpowers on top of Claude Code, this should feel familiar. Those are orchestration layers that bolt onto Claude Code to do roughly what Goals does natively in Codex with a single /goal command. The whole pitch is: same outcome, none of the orchestration overhead.

How Do You Enable Goals in Codex?

Goals is experimental, so it's off by default. Two ways to turn it on:

1. Open Codex settings → Configuration → click "Open config.toml." The file opens in your editor. Add these two lines if they're not already there:

[features]
goals = true

2. Or just tell Codex to do it for you: "Hey, can you enable goals for me?" It'll edit config.toml itself.

After enabling, restart Codex. This matters — the change won't always pick up live. Once restarted, type /goal and submit. You won't get the usual visual confirmation that a slash command is active (probably a UI bug since the feature is experimental), but you'll see a small goal badge appear in the chat header once you submit your first prompt with it. That badge is how you know the loop is running.

Same command works in both the desktop app and the CLI. Setup takes about ten seconds total.

How Does a Goals Loop Actually Work?

To understand what Goals is doing, it helps to first understand a Ralph loop. A Ralph loop is essentially one line of bash that runs Claude Code (or any agent) in a while loop, pointed at a prompt.md file. The prompt declares the objective and the completion criteria — for example, "raise test coverage on auth files to 75%." Each loop iteration spins up a fresh agent session, the agent reads prompt.md and a state.md file (which tracks what's been done across turns), executes one turn of work, updates state.md, and the loop continues. When the completion criteria are hit, the loop exits.

Simple, but it has gaps. Ralph loops don't gracefully handle budget limits, crashes, or completion verification — if you blow through your token cap mid-task, you're just done. If the agent crashes, the loop has no recovery path. And there's no built-in third-party check to confirm the goal is actually complete versus the agent claiming it is.

Goals fills those gaps with two extra invisible files: continuation.md and budget_limit.md. At the end of every turn, Codex evaluates one of four paths:

• Work remaining + budget OK — keep running.
• Approaching budget cap — inject budget_limit.md, wrap up the turn gracefully, write a final report on what's done and what's still needed.
• Goal complete — make an update_goal tool call, audit deliverables against the verification criteria, and exit if everything passes.
• Crash or pause — handled with continuation logic instead of just dying.

So it's the same big-picture idea as a Ralph loop, but with graceful budget handling, crash recovery, and a built-in completion audit baked in.

How Do You Use Goals on a Real Project?

The critical move: use plan mode first. Goals will run as long as it takes to satisfy your verification criteria, which means vague criteria produce vague (and potentially endless) results. "Make me a SaaS that earns a billion dollars" is not a goal. "Run npm run build clean, start the dev server, run an automated Playwright script that confirms the canvas isn't blank, simulates keyboard input, forces damage, and verifies health changes" — that's a goal.

My workflow:

1. Open a fresh chat in plan mode.
2. Describe the project at a fuzzy level ("top-down arcade survival game with a player drone, three enemies, a boss, hazard mines, original assets, etc.").
3. Let Codex turn it into a tight plan with explicit verification steps.
4. When it asks if you want to implement, say no — "I'll tell you what to do."
5. Then run /goal use goal to implement this plan.
6. Submit and walk away.

The verification block is the most important section to read carefully. If the verification reads "build runs, dev server starts, Playwright confirms canvas non-blank, simulates movement, simulates collectible event, forces damage, confirms health change, confirms boss win state UI" — and that list represents what "done" means to you, you're good. If the verification doesn't represent done, Codex will declare done before you'd consider it done. Tighten the criteria, then submit.

What Did Codex Goals Actually Build in 30 Minutes?

I tested it on Rift Salvage — a 2D arcade survival game with all original visual assets. The prompt asked for a player drone sprite, three enemy types, a boss creature, an energy core, hazard mines, a rift background, badges, two UI flavor assets, plus working keyboard/touch controls, scoring, shield power-ups, a boss phase with win/lose/pause/restart states, and a Playwright verification script.

Codex finished the first pass in about 30 minutes. It generated 11 image-gen bitmap assets with alpha cutouts using OpenAI's image generation model — meaning every sprite was original. (One of Codex's real advantages over Claude Code on visual projects: native access to GPT image generation. With Claude Code, you'd need to wire up Higgsfield CLI or an MCP server to get equivalent capability.) The local dev server was running at the end. The game booted, controls worked, enemies spawned and chased, mines deployed, the boss phase fired.

First-pass critique: contrast was a little flat (sprites blended into the background) and there was no shooting system — you could dodge enemies but not engage them. So I dropped a follow-up prompt back into plan mode asking for a combat system, faster boss-phase trigger, and a contrast pass.

One important Goals quirk: each goal run is tied to the chat session it started in. To run a second goal pass on the same project, you have to open a new chat — copy the new plan, open a fresh chat tab, paste, run /goal. Same files, same project directory, new goal thread.

Fifteen minutes later, the second pass landed. Combat system worked, enemies returned fire with hit points, a manual boss-trigger button appeared, the contrast was readable. Forty-five minutes total, two hands-off Goals runs, working game with original assets, automated verification.

How Does Codex Goals Compare to GSD or Superpowers on Claude Code?

Goals is what you'd build if you took GSD's philosophy and shipped it as a single platform feature. Both are autonomous-execution layers. Both keep state across turns. Both verify completion criteria before exiting. The difference is friction.

GSD and Superpowers are external orchestration repos that wrap Claude Code. They're powerful, but they require setup, learning the orchestration model, and watching a 40-minute demo to use confidently. Goals is a slash command. You enable a feature flag, type /goal, and Codex goes.

If you've already invested in GSD on Claude Code and have it tuned, keep using it — the flexibility is real. If you're starting fresh and want autonomous long-runs without learning a new framework, Goals is a faster on-ramp.

A few practical notes:

• Goals doesn't replace Claude Code — they pair well together. Plan in Claude Code, copy the plan into Codex, run /goal, then have Claude Code review the diff after.
• Goals shines on long-horizon work with quantifiable completion (game features, test coverage, refactor sprints, scraping pipelines). It's overkill for a five-minute change.
• The 50-hour goal runs people are screenshotting on social media are real but probably not optimal — diminishing returns kick in. Tighter, repeated runs with checkpoints tend to outperform one massive marathon.

Frequently Asked Questions

Is Codex Goals only available in the desktop app?

No. Goals works in both the Codex desktop app and the Codex CLI. Same /goal command, same config.toml flag. The desktop app gets you a few extras (in-app browser, diff viewer, the goal badge UI) but the loop itself behaves identically in either surface.

How do I run a second Goals pass on the same project?

Open a new chat. Each Goals run is scoped to the chat thread it started in, so re-running /goal in the same chat continues the existing thread instead of starting a fresh loop. Open a new chat, paste your next plan, then /goal it. Same project directory, new goal thread.

What happens if Codex hits its token budget mid-Goals run?

Unlike a raw Ralph loop, Codex injects a budget_limit.md file and gracefully wraps up the turn. You'll get a final report on what's been completed and what still needs to be done, so you can resume after upgrading or topping up. No silent failure, no half-broken state — just a clean handoff back to you.

Can I edit or pause an active Goals run?

Yes. Goals supports pause, edit, and crash recovery as part of the loop's turn-end logic. If something goes wrong (your machine sleeps, an MCP server crashes, you Ctrl-C out), Goals can resume rather than treating it as a hard stop the way a basic bash Ralph loop would.

Should I use Goals on Codex or stick with Claude Code + GSD?

If you're already deep on Claude Code with GSD or Superpowers configured the way you like, no rush to switch. The reason to look at Goals is friction. It's one slash command versus an entire orchestration framework. For new long-running tasks, especially anything visual where Codex's image generation is an advantage, Goals is the lower-overhead path. The best play is using both — let Codex run the autonomous build, let Claude Code review the diff after.

---

If you want to go deeper into running Codex and Claude Code in tandem on autonomous workflows, join the free Chase AI community for templates, prompts, and live breakdowns. And if you're serious about building with AI, check out the paid community, Chase AI+, for hands-on guidance — including the full Codex Masterclass alongside the Claude Code Masterclass.