OpenAI’s Codex CLI just gained something that looks small on the surface and much larger once you inspect the implementation: /goal. In the official 0.128.0 release notes for the OpenAI Codex repository, OpenAI describes the feature as “persisted /goal workflows with app-server APIs, model tools, runtime continuation, and TUI controls for create, pause, resume, and clear” (OpenAI Codex 0.128.0 release). That single bullet is doing a lot of work. /goal is not merely another slash command. It is a new goal lifecycle inside Codex: a way to tell the agent what durable objective it should keep pursuing across turns, interruptions, resumes, and budget boundaries.
The short version is this: /goal lets a user define a longer-running objective for Codex, rather than issuing one isolated instruction at a time. Instead of asking Codex to “do this next thing,” you can give it a goal that remains attached to the thread. The implementation then gives Codex a persistent state record, app-server APIs, constrained model tools, runtime continuation behavior, and terminal UI controls for managing that goal. That is why the release notes mention five separate pull requests — persistence, app-server API, model tools, runtime, and TUI — rather than a single UI patch (PR #18073, PR #18074, PR #18075, PR #18076, PR #18077).
That architecture matters because Codex is not just a chatbot with code suggestions. OpenAI describes Codex as “a coding agent that helps you build and ship with AI,” designed for real engineering work such as features, refactors, migrations, reviews, and releases (OpenAI Codex product page). In OpenAI’s original Codex announcement, Codex was introduced as a cloud-based software engineering agent that can write features, answer questions about a codebase, fix bugs, and propose pull requests, with work running in isolated environments and results backed by terminal logs and test outputs (Introducing Codex). /goal brings that same agentic philosophy into the local Codex CLI experience: not just “answer me,” but “continue working toward this engineering outcome.”
What /goal Is
At the user-facing level, /goal is a slash command in Codex CLI’s TUI. The merged TUI pull request says it added /goal summary rendering for the current goal, /goal <objective> creation or replacement, and control commands including /goal clear, /goal pause, and /goal unpause (PR #18077). The 0.128.0 release notes describe the final released controls as “create, pause, resume, and clear,” and the same release changelog includes a follow-up item, “Use /goal resume for paused goals” (OpenAI Codex 0.128.0 release). So the safest reading is: /goal gives users a command surface for creating a goal, viewing it, pausing it, resuming it, and clearing it.
That is the visible feature. Underneath, though, /goal is a persisted thread-level state machine. The first foundational PR says goal mode needed “durable thread-level state” before clients or model tools could safely build on it. That PR added a goals feature flag, a thread_goals state table, a Rust model for persisted thread goals, APIs for creating, replacing, updating, deleting, and accounting goal usage, and goal_id-based stale update protection (PR #18073). In plain English: Codex now has an internal record of the goal attached to a thread, what state it is in, and how much time or token usage has been accounted against it.
That is what separates /goal from a prompt. A prompt is just input. A goal is state.
The distinction is subtle but huge. If you type “refactor the authentication layer” as a normal prompt, Codex can work on that turn and then stop. If you set it as a goal, Codex has a durable objective that can survive across the workflow. The implementation tracks whether a goal exists, what objective it tracks, whether it is active, paused, budget-limited, or complete, and how much usage has been spent (PR #18073). That means the agent can reason in terms of an ongoing commitment, not only the current message.
What /goal Is For
The purpose of /goal is long-horizon engineering work. A GitHub issue opened after the release captures the user-facing intuition well: users need a reliable way to tell Codex, “keep working toward this objective until it is actually done, verify against the current state, and only stop when complete or blocked” (GitHub issue #20536). That issue is not an official OpenAI announcement, so it should not be treated as product documentation. But it is useful evidence of how the command is being discovered by users: as a first-class workflow for sustained objectives rather than one-off turns.
OpenAI’s own Codex positioning points in the same direction. The Codex product page says Codex is built to drive “real engineering work,” including routine pull requests, hard problems, complex refactors, and migrations (OpenAI Codex product page). The original Codex announcement says early use cases included refactoring, renaming, writing tests, scaffolding new features, wiring components, fixing bugs, drafting documentation, triaging on-call issues, and planning tasks at the start of the day (Introducing Codex). Many of those tasks are not single-turn jobs. They require context, checking, iteration, and sometimes multiple passes through the codebase.
That is where /goal fits. It is for tasks where “do X” is too shallow, but “continue pursuing X until the goal is achieved or constrained” is exactly right. Examples include:
- “Migrate this package from the old API client to the new one.”
- “Increase test coverage for the billing module until the critical paths are covered.”
- “Refactor the CLI command parser without changing behavior.”
- “Find and fix the flaky integration tests in this repo.”
- “Modernize the TypeScript types around this feature.”
- “Work through this bug until you can reproduce it, fix it, and verify it.”
Those examples are illustrative; the sourced fact is that Codex is positioned for feature work, refactors, migrations, testing, bug fixing, and documentation (OpenAI Codex product page, Introducing Codex). /goal gives that kind of work a persistent control loop.
How It Works Under the Hood
The /goal rollout was built in layers, and those layers explain the feature’s importance.
First came persistence. OpenAI added durable goal state for a thread, including status, objective, active/paused/budget-limited/complete state, token usage, elapsed time, and stale update protection (PR #18073). Without this layer, /goal would be a decorative command. With it, the CLI and runtime have something real to coordinate around.
Second came the app-server API. The app-server PR added v2 RPCs: thread/goal/get, thread/goal/set, and thread/goal/clear, plus notifications named thread/goal/updated and thread/goal/cleared so clients can keep local goal state synchronized (PR #18074). It also added resume and snapshot wiring so reconnecting clients see the current goal state for a thread (PR #18074). That means goals are not merely local UI text; they are part of the app-server protocol surface.
Third came model-facing tools. OpenAI added get_goal, create_goal, and update_goal behind the goals feature flag (PR #18075). This is especially interesting because the PR explicitly constrains the model’s power. create_goal can create only when no goal exists, and update_goal exposes only goal completion. Pause, resume, clear, and budget-limited transitions remain user- or runtime-controlled (PR #18075). That design is important: it gives the model enough awareness to participate in goal workflows without giving it broad control over all goal state.
Fourth came core runtime behavior. The runtime PR says a long-running goal should be “a core runtime concern,” because core owns turn lifecycle, tool completion boundaries, interruptions, resume behavior, and token usage (PR #18076). This PR added continuation turns, accounting at turn/tool/mutation/interrupt/resume boundaries, budget-limit steering, interrupt pause behavior, resume auto-activation, and suppression of repeated automatic continuation when a continuation turn makes no tool calls (PR #18076).
Fifth came the TUI. The TUI PR added the actual /goal user experience: summary rendering, command variants, confirmation when replacing an existing goal, footer/statusline indicators, elapsed time and token budget display, handling of goal notifications, and notification suppression when a goal is still active and follow-up work is expected (PR #18077).
Put together, this is a full agent workflow, not a syntactic shortcut.
What Makes It Amazing
The most impressive part of /goal is that it makes agentic persistence explicit. Many coding agents can continue if you keep prompting them. /goal gives the continuation a formal object: a goal with lifecycle, state, controls, and accounting.
That matters because engineering is full of partially completed work. A real developer does not just respond to one message and vanish. They hold an objective in mind, inspect the repo, make changes, run tests, discover failures, revise, and continue. OpenAI’s original Codex announcement emphasized that Codex can run commands such as test harnesses, linters, and type checkers, and that users can monitor progress, review changes, request revisions, open pull requests, or integrate changes locally (Introducing Codex). /goal pushes the CLI closer to that “ongoing collaborator” model.
The second amazing thing is that /goal respects interruption and control. The runtime PR says active goals pause on interrupt and auto-reactivate on resume outside plan mode (PR #18076). The TUI adds direct commands to pause, resume, and clear goals (OpenAI Codex 0.128.0 release, PR #18077). This is critical because autonomy without controls is dangerous and annoying. A goal-oriented agent must know when to keep going, but it must also give the user obvious ways to stop, pause, or reset the objective.
The third amazing thing is budget awareness. The runtime PR says token budget exhaustion is treated as a “soft stop”: the goal is marked budget_limited, and Codex injects wrap-up steering rather than simply aborting the active turn (PR #18076). That is a thoughtful design. Budget exhaustion is not necessarily failure. It is a constraint. A good agent should summarize where it got, what remains, and why it stopped. The TUI also displays token budget information when a budget exists from API/tool-created goals (PR #18077).
The fourth amazing thing is the separation of powers between user, model, runtime, and UI. The user can create, pause, resume, replace, or clear goals. The model can inspect goals, create them only in constrained circumstances, and mark completion. The runtime handles continuation, accounting, interruptions, and budgets. The app-server synchronizes state. The TUI displays and controls it. This division is visible across the five implementation PRs (PR #18073, PR #18074, PR #18075, PR #18076, PR #18077).
The fifth amazing thing is discoverability — or, more precisely, the fact that discoverability is now the weak link because the underlying capability is real. The open documentation issue says /goal exists in codex-cli 0.128.0, but the public CLI slash-command docs checked by the issue author did not list it at the time (GitHub issue #20536). Again, that issue is not official documentation, but it highlights a practical point: when a feature this significant is buried in release notes and PRs, users may not realize Codex can do it.
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.”
Why Developers Should Care
For individual developers, /goal could reduce the overhead of babysitting an agent. Instead of repeatedly nudging Codex with “continue,” “now run tests,” “fix the next failure,” and “keep going,” you can express the desired end state more directly. The runtime is explicitly designed to schedule continuation turns only when the session is idle, while pending user input and mailbox work take priority (PR #18076). That suggests a workflow where the agent continues when appropriate but does not override the user’s next instruction.
For teams, /goal fits the broader Codex direction. OpenAI’s Codex product page talks about multi-agent workflows, background work, code understanding, prototyping, documentation, code review, and raising baseline quality through thorough designs and testing (OpenAI Codex product page). Goals are a natural primitive for that world. If agents are going to work across tasks, tools, and sessions, they need explicit objectives and lifecycle controls.
For safety and reliability, /goal is also encouraging because it is not just “let the model run forever.” The implementation includes feature gating, persisted state, stale update protection, constrained model tools, budget accounting, interrupt handling, and user-visible controls (PR #18073, PR #18075, PR #18076, PR #18077). OpenAI’s original Codex announcement also stresses that users should manually review and validate agent-generated code before integration and execution (Introducing Codex). /goal does not remove that responsibility. It makes the agent more persistent, which makes human review more important, not less.
The Bottom Line
/goal is one of those features that sounds like a command but is really a product direction. It gives Codex a durable objective. It lets the CLI represent that objective in the UI. It gives the app-server a way to sync it. It gives the model constrained tools to understand and complete it. It gives the runtime responsibility for continuation, interruptions, budgets, and stopping behavior.
That is why the release note is so dense: “persisted /goal workflows with app-server APIs, model tools, runtime continuation, and TUI controls” (OpenAI Codex 0.128.0 release). Each part matters. Persistence makes the goal real. APIs make it observable. Tools make it model-aware. Runtime continuation makes it agentic. TUI controls make it usable.
If Codex is moving from code assistant toward coding partner, /goal is a key primitive. It changes the interaction from “answer this prompt” to “pursue this outcome.” And for software engineering, where valuable work often takes multiple steps, multiple checks, and multiple revisions, that is a much more natural shape.
