Goal mode cannot increase its token budget and resume after becoming budget_limited

What variant of Codex are you using?

Codex App / Goal mode (/goal). This likely also affects other clients that use the same thread-goal runtime.

What issue are you seeing?

When a Goal reaches its configured token budget, it enters the budget_limited state and stops substantive work. There does not appear to be a reliable user-facing way to increase that Goal's token budget and resume the same Goal.

Asking Codex to “increase the Goal budget”, “add more tokens”, or “continue with a larger budget” does not reliably update the persisted Goal. The existing Goal remains budget_limited, and the user may be forced to clear the Goal, create a new one, or manually continue outside Goal mode.

This is specifically about the per-Goal token budget, not the user's ChatGPT/Codex subscription quota or rate limit.

Steps to reproduce

1. Start a Goal with an explicit token budget, or open a thread whose active Goal already has a finite token_budget.
2. Let the Goal consume that budget.
3. Observe that the Goal becomes budget_limited and automatic continuation stops.
4. Ask Codex to increase or extend the Goal budget and resume the same objective.
5. Observe that there is no clear command or desktop UI for changing the persisted budget, and the Goal does not reliably return to active with the larger budget.

Expected behavior

Users should be able to extend an existing Goal without losing its objective, progress, or history. For example, Codex could support one or more of:

• /goal budget 400000 — set a new total token budget;
• /goal budget +200000 — add an incremental allowance;
• an Increase budget and resume action when a Goal becomes budget_limited;
• an app-server / agent API that atomically updates token_budget and changes the status from budget_limited back to active.

The UI should show:

• tokens already used;
• previous and new total budget;
• the source of the budget change;
• confirmation that the same Goal has resumed.

Increasing the budget should preserve tokens_used; it should not reset accounting or silently create a different Goal.

Actual behavior

Once the Goal is budget_limited, the budget behaves like an immutable terminal limit from the user's perspective. Resume alone is insufficient because the persisted budget has already been exhausted, while clearing/recreating the Goal loses the existing Goal lifecycle and progress tracking.

Why this matters

Long-running coding and research tasks are difficult to estimate in advance. A budget should act as a controllable safety boundary, not permanently strand the Goal when the user explicitly approves more work.

This is also important for budgets that were set accidentally or inferred too conservatively. The previously closed issue #24629 addressed Goals assigning an unrequested token budget, and its original suggested fixes included allowing users to clear or extend an accidental budget. That issue was closed after strengthening the prompt against unsolicited budgets, but the separate recovery path—extending an existing budget-limited Goal—still needs a first-class UX.

Suggested safety behavior

• Require explicit user confirmation before increasing a Goal budget.
• Clearly distinguish Goal-local token budget from account usage limits.
• Refuse to resume if the account itself is usage-limited, while preserving the updated Goal budget for later.
• Record budget changes in the Goal history for auditability.