Updated August 26, 2026: aligned this guide with OpenAI's current /goal documentation and removed unsupported pricing, access, and separate-mode assumptions.
Verdict: Codex /goal gives Codex one durable objective for long-running work across turns. It is not a separate model, a guarantee of unlimited execution, or a substitute for permissions. It works best when the objective, constraints, validation loop, and stopping condition are explicit.
What does /goal do in Codex?
OpenAI describes /goal as a way to give Codex a durable objective for long-running work. A normal prompt asks for one response or one bounded implementation. A goal tells Codex what outcome to keep pursuing across turns until it reaches a verifiable stopping condition or needs the user.
The command is designed for work such as migrations, large refactors, experiments, prototypes, games, and deployment retry loops. These jobs benefit from repeated cycles of inspect, change, test, and evaluate. A loose backlog of unrelated tasks is a poor goal because there is no single finish line.
Codex /goal commands
| Command | What it does | When to use it |
|---|---|---|
| /goal <objective> | Creates a durable objective | Start long-running work with a clear end state |
| /goal | Shows the current goal | Check objective, progress, or status |
| /goal edit | Changes the objective | Correct scope or update the finish line |
| /goal pause | Pauses goal work | Stop the run without discarding the goal |
| /goal resume | Resumes a paused goal | Continue toward the same objective |
| /goal clear | Removes the current goal | End or replace the objective |
OpenAI's documentation says the objective must be non-empty and can be up to 4,000 characters. The best objectives are much shorter: enough detail to define success, not a full project archive.
A good /goal prompt
OpenAI's starter form is:
/goal Complete [objective] without stopping until [verifiable end state].
A stronger engineering version adds scope, exclusions, evidence, and a stop rule:
/goal Upgrade this repository from framework X to Y. Preserve public API behaviour,
do not deploy or change production data, run the existing test suite after each
milestone, and stop only when all tests pass and the migration checklist is complete.
That prompt tells Codex what to achieve, what not to touch, how to validate progress, and when to stop. It also avoids granting authority for deployment or other external actions.
When /goal is the right tool
Use /goal when all four conditions are true:
- The work is larger than one normal turn.
- Codex can make useful progress without constant product decisions.
- There is a repeatable validation loop.
- The stopping condition can be checked.
Examples include converting a codebase while keeping tests green, reducing benchmark latency below a stated threshold, finishing a game prototype with a fixed feature list, or repairing a test suite until a known failure count reaches zero.
Do not use /goal as a vague instruction to "improve everything" or "keep making the site better." Those objectives invite scope drift and make completion subjective.
How goals interact with permissions
A goal changes persistence, not authority. File permissions, network access, approvals, production-write rules, and browser confirmations still apply. If a goal needs a destructive command, deployment, purchase, public post, or credential, Codex may still need explicit authorization.
This distinction is important for long-running work. A durable objective can keep the reasoning loop alive, but it should not silently broaden the systems, data, or people placed in scope.
Validation and stopping conditions
A useful stopping condition is binary or measurable:
- All tests pass on the specified command.
- The migration checklist has no open items.
- The benchmark stays below a defined limit for three runs.
- The artifact renders without the listed visual defects.
- The target files match a schema and the validator exits zero.
"Looks good" is weak because it depends on taste. "All 42 acceptance checks pass" is strong because Codex can prove it.
The goal should also say when to stop and ask for help: missing credentials, an unresolved product decision, a repeated environment failure, or a required external approval. Persistence should not become blind repetition.
Enabling /goal
If /goal does not appear in the slash-command list, OpenAI says to enable the goals feature in config.toml:
[features]
goals = true
OpenAI also documents the CLI command:
codex features enable goals
Feature availability can vary by app version and environment. Use the current official documentation rather than assuming an older command surface.
/goal versus scheduled tasks and ordinary prompts
| Tool | Best for | Persistence | Typical stop condition |
|---|---|---|---|
| Ordinary prompt | One bounded task or answer | One turn or active task | Requested output delivered |
| /goal | One durable objective with iterative work | Across turns | Verifiable objective reached |
| Scheduled task | Work that should run at a future or recurring time | Schedule-driven | Each scheduled run completes |
A goal is not a scheduler. If a job must run every morning or on a fixed date, use a scheduled task. If it must keep improving one outcome through repeated work now, /goal is the better fit.
What is update_goal?
Users may see references to goal-status updates in agent traces or technical queries. The user-facing control is the /goal command surface. Internal status updates help the system record that an objective is complete or genuinely blocked; they are not a separate product the user needs to call with invented JSON.
For editorial accuracy, examples should focus on documented slash commands. Internal tool schemas can change and should not be presented as a stable user API unless OpenAI publishes them as such.
Useful distinctions and related reading retained from the verified current article
How /goal Differs From Nearby Ideas
/goal is easy to confuse with planning, resuming, or compaction, but it is different.
A plan is typically a structured outline of steps. A goal is the durable objective that the agent is pursuing. The release notes mention both /goal and plan-mode nudges as separate features in 0.128.0, which supports the idea that they are adjacent but distinct (OpenAI Codex 0.128.0 release). A plan might say “first inspect tests, then update code, then run validation.” A goal says “keep working until the migration is complete or you are blocked.”
Resume is about continuing a session or thread. /goal is about what objective should remain active inside that thread. The app-server goal API added resume/snapshot wiring so reconnecting clients see current goal state, which implies goal state participates in resume behavior but is not identical to resume itself (PR #18074).
Compaction is about managing context. The docs issue explicitly says its /goal documentation request is separate from goal-retention or compaction behavior (GitHub issue #20536). In other words, /goal is not “summarize the chat.” It is “hold this objective as the thing to pursue.”
What the evidence supports
/goal adds a durable objective, explicit lifecycle controls and persisted state to Codex CLI. The public implementation shows how the app server, model tools and runtime coordinate that state across turns and interruptions.
That makes /goal useful for work that spans several steps, but it does not prove better code quality or safe autonomous completion. Teams still need task budgets, tests, review and clear stopping conditions. Evaluate it against representative repositories before adopting it as a standard workflow.
Related Guides
- The Complete Guide to OpenAI Codex
- OpenAI Codex Command Guide
- The Codex App Super Guide (2026): From “Hello World” to Worktrees, Skills, MCP, CI, and Enterprise Governance
- Loops, Not Prompts: How Advanced AI Users Are Turning Codex, Claude Code, and LLMs Into Real Workflows
Continue Reading
Common /goal mistakes
- Combining unrelated backlog items into one objective
- Omitting the validation command
- Forgetting exclusions such as "do not deploy"
- Using a subjective finish line
- Assuming persistence grants production authority
- Continuing after evidence shows the approach is failing
- Clearing the goal before preserving the final evidence
FAQ
What does /goal do in Codex?
It gives Codex one durable objective to pursue across turns toward a verifiable stopping condition.
How do I create a Codex goal?
Enter /goal followed by the objective. Include scope, constraints, validation, and the exact end state.
Can I pause and resume a goal?
Yes. OpenAI documents /goal pause and /goal resume, along with view, edit, and clear controls.
Is /goal a separate paid mode?
OpenAI documents it as a Codex workflow and slash command, not as a separate model or separately priced product mode. Account usage rules still apply.
Will /goal deploy or publish automatically?
Not unless that action is within scope and properly authorized. Goals do not override approval, permission, or production-safety rules.
Official OpenAI documentation
The Kingy Brief
Follow The Kingy Brief.
One consequential launch, one pricing, limit, or shutdown change, one hands-on test, one exact prompt or Test Pack, and one try / watch / skip verdict.
Free · Choose your subjects · Double opt-in · Unsubscribe anytime