Repository navigation
Expose Goal controls outside the interactive TUI, both for external automation and agent-side workflows. #31783
Description
What variant of Codex are you using?
CLI
What feature would you like to see?
Feature request: expose Goal controls outside the interactive TUI, both for external automation and agent-side workflows.
Current behavior:
/goal resumeworks in the interactive TUI.codex exec resume <SESSION_ID> "resume the goal..."resumes the thread, but does not flip the internal Goal state from paused/blocked to active.- Prompting the agent to resume the goal is therefore not equivalent to the
/goal resumeslash command. - The agent can call
get_goal()and observe goal status, timeUsedSeconds, tokensUsed, etc., but cannot resume or pause the goal through a tool.
Why this matters:
I want to automate long-running Goal work while respecting usage/rate limits. The clean path would be a scheduler or codex exec resume, but Goal mode currently requires manual TUI intervention to resume.
Without a noninteractive Goal control, the fallback is brittle UI automation such as sleeping and using xdotool to type /goal resume into the TUI.
Requested external/API surface:
Please add documented noninteractive Goal commands, for example:
codex goal status <SESSION_ID> --jsoncodex goal resume <SESSION_ID>codex goal pause <SESSION_ID>codex goal clear <SESSION_ID>
Or equivalent flags on codex exec resume, for example:
codex exec resume <SESSION_ID> --goal-resume "continue working..."codex exec resume <SESSION_ID> --goal-status --json
Requested agent-side tool surface:
Please also consider exposing Goal lifecycle tools to the agent, complementing the existing get_goal() tool:
resume_goal()pause_goal()- possibly
clear_goal() - possibly
get_usage()/get_rate_limits()for the same data shown by/statusor/usage
Useful semantics:
resume_goal()should resume an existing paused/blocked goal without changing the objective.pause_goal()should pause work without marking the goal complete or blocked.- These tools should return the same accounting fields as
get_goal(), including status, timeUsedSeconds, tokensUsed, and objective. - They should be available in both interactive sessions and
codex exec resumeruns, subject to policy. - Transitions should be auditable in the transcript, like
update_goal.
Concrete use case:
A user wants to run bounded unattended Goal work from cron/systemd or another scheduler:
- Resume the saved Codex thread.
- Resume the existing Goal.
- Let the agent work for a user-defined slice, e.g. 20 minutes of Goal time.
- Have the agent pause/stop before the cap.
- Repeat later when rate limits have reset.
Today, step 2 requires the TUI slash command or app UI. A first-class CLI/API/tool surface would make this workflow reliable without UI automation.
Additional information
Codex wrote the feature request, but I reviewed it and LGTM. Whole point was to really push the /goalmaxxing to its logical (and perhaps absurd but we'll see 😄) conclusion, hahaha!
Activity
Cheaterman commentedon Jul 9, 2026
BTW, codex itself suggested thread automations in the Codex app, but then when I later insisted on seeing how that would interact with the internal flags/accounting of
/goal, it figured that's far from a hard guarantee and could probably benefit from the same "levers to pull" (so to speak) being implemented.github-actions commentedon Jul 9, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
JesmonX commentedon Jul 18, 2026
There is a related but narrower startup use case in addition to controlling an existing Goal:
codex goal "finish the migration"This would open the normal interactive TUI, create the prompt as the new active thread Goal through the existing Goal lifecycle, and then continue the session. The prompt should not become an ordinary initial
UserTurn. Standard interactive flags (--model,--profile,--config,--image,--remote, sandbox/approval options, etc.) should continue to work.This differs from the pause/resume/status operations requested here: it creates a new Goal at session startup. A matching
codex plan "..."startup subcommand is discussed in #13377.RongNianXin commentedon Oct 4, 2026
Additional Windows desktop evidence: natural-language pause/resume asymmetry
I encountered a related case in Codex Desktop on Windows. The installed Windows package reports
OpenAI.Codex 26.928.3736.0(package version, not independently verified against the About dialog).Observed sequence in an existing Goal thread:
pausedand that it had no interface to restoreactive. The desktop Goal row still showed a paused Goal. Continuing the current chat turn did not resume Goal mode./goal resumein the desktop composer opened a replacement confirmation dialog. The dialog said the saved objective would be replaced, and the proposed new objective was literallyresume. It did not act as a resume command. This is evidence about the desktop composer; I am not claiming that the interactive CLI command is broken.Please provide a supported way for the agent to resume an existing Goal with the user's authorization, preserving the objective and usage accounting. If resuming is intentionally limited to the UI, the agent should explain that before proceeding and distinguish ordinary task work from resuming the Goal. If desktop slash subcommands are unsupported, the composer should explain this rather than offer to replace the objective with
resume.I have not independently rerun this in a clean thread or inspected the private state database. Raw screenshots and project/session details are omitted for privacy. This is an additional desktop observation for the existing lifecycle-control request, not a claim that all Goal controls are unavailable.