Add wait/wake support for goals without spending tokens

[jerryfane]

What variant of Codex are you using?

CLI/TUI and app-server goal runtime. This also matters for SDK/app-server integrations that drive long-running goals.

What feature would you like to see?

Add first-class wait/wake support for goals so a goal can stop making model calls while it is waiting for time or an external event, then continue when the wait condition is satisfied.

Current behavior, as I understand it from the goal runtime:

• Active /goal work continues automatically when the thread becomes idle.
• /goal pause and /goal resume already let a user stop and restart continuation manually.
• Blocked, usage-limited, budget-limited, and complete statuses stop automatic continuation.
• There is not currently a durable "waiting" state that can be resumed automatically by a timer or external signal without spending tokens during the wait.

The missing capability is useful for goals like:

• "Check CI until it finishes, then fix failures."
• "Wait until the deployment completes, then verify it."
• "Poll this external job occasionally, but do not burn tokens while nothing can be done."
• "Resume this goal when another process/webhook tells Codex there is new information."

A good shape might be to separate "goal continuation" from "wait scheduling", similar to how other agent harnesses separate active goals from loop/scheduler primitives:

• A goal can enter a waiting state with a bounded reason and optional wakeAt timestamp.
• While waiting, the runtime must not start another model turn or consume tokens.
• A waiting goal can be resumed by user action, an app-server API call, a timer, or a future external-event/channel mechanism.
• Waiting state should be persisted so it survives app/server restart and thread resume.
• Goal update notifications should expose the waiting state and wake metadata to clients.

A small first stage could avoid building every event source at once:

1. Add a persisted waiting goal status with optional wakeAt/reason metadata.
2. Teach the idle continuation path to treat waiting like paused for token usage.
3. Add an app-server way for clients/supervisors to wake the goal by setting it active again.
4. Optionally add a later scheduler that wakes goals at wakeAt.

Additional information

I searched existing issues/PRs and found adjacent work, but not an exact request for durable wait/wake semantics:

• goal: pause continuation loops on usage limits and blockers #23094 added blocked/usage-limited statuses so continuation loops pause on blockers and usage limits.
• /goal when blocked doesn't stop but keeps looping consuming tokens and API credits #23177 reported blocked goals continuing to consume tokens; this appears addressed by goal: pause continuation loops on usage limits and blockers #23094.
• /goal: chat "stop" message causes silent token burn until usage limit (autonomous tick ignores LLM-level self-restraint) #24531 discussed active goals continuing despite a chat-level "stop" message; maintainers clarified active goals are intended to keep going and users should pause/clear them.
• codex exec resume should support promptless follow mode for active goals #24016 / Allow promptless exec resume for active goals #24321 cover promptless exec resume/follow behavior for active goals, which is related to supervising goals but not the same as a no-token waiting state.
• /goal runtime includes approval-wait time #22312 covered approval-wait time accounting, which is also adjacent but narrower.

Prior-art note: Claude Code appears to expose this kind of separation through /goal for autonomous continuation, /loop for scheduled prompts, and channels/webhooks for external events. OpenCode appears to support similar patterns mostly through plugins/community tooling rather than a core built-in. The Codex version does not have to copy those interfaces exactly, but the product need seems similar: let long-running goals wait without spending tokens, then wake from time or outside state.