Support durable delayed Goal continuation and owner-synchronized external state changes

What variant of Codex are you using?

Codex App (desktop).

What feature would you like to see?

Please support durable delayed continuation for Goals, with native desktop-owner semantics.

Why this is needed

Agents frequently reach a state where no useful model work can continue until an external result exists, for example:

• a GitHub Actions CI run is still executing;
• another Codex thread is implementing or reviewing a dependency;
• an external service or user-controlled environment will not be ready for some time.

Keeping the Goal active during such waits can produce continuation turns with no actionable work, consume model tokens and compute, encourage repeated polling, and risk duplicate decisions. Ending the Goal entirely loses the intended continuation. The desired behavior is a goal-aware dormant state: finish the current turn, suppress native continuation while nothing can be done, and resume the same Goal exactly once when the selected condition becomes actionable.

This is not a request for a general background-job scheduler. It is a bounded lifecycle control for one existing Goal.

A useful API could provide either or both of these capabilities:

1. Native delayed or event-driven Goal continuation

   • An agent, or a user instruction handled by an agent, can defer the current Goal until resume_at, a bounded delay, completion of a named CI run, or a response from a named existing thread.
   • The current turn is allowed to finish normally.
   • The dormant interval starts no model turn and performs no model-driven polling.
   • No native Goal continuation starts before the time or event becomes due.
   • At the deadline or event, Codex reactivates the same Goal and starts exactly one continuation.
   • The schedule is durable across app restarts, bound to the exact thread and Goal identity, cancellable, idempotent, and limited to one active schedule per Goal.
   • On wake, the continuation reads the current Goal state and the fresh external result before deciding what to do; it does not blindly replay the pre-wait plan.

2. Owner-synchronized external Goal control

   • An external app-server or IPC client can set the Goal state through a supported API.
   • A paused or active change is applied to the loaded desktop owner's in-memory conversation state with the same semantics as clicking the App's Pause Goal or Resume Goal control.
   • The acknowledgement is returned only after the owner has applied the transition.
   • Pending continuation decisions are cancelled or recomputed from the new state, and state notifications propagate across app-server processes.

The key invariant is: once a delayed pause is acknowledged, only the due scheduler or matching event may reactivate the Goal before the deadline.

Additional information

A separate app-server client can persist thread/goal/set as paused while the loaded desktop owner still retains an active in-memory Goal and schedules another native continuation. The UI Pause Goal control does not have this mismatch because it updates both persisted state and the desktop owner's local state.

This makes external durable scheduling unreliable unless tooling drives the visible UI. A native delayed/event-driven continuation API would be the cleanest solution; owner-synchronized external state changes would also make existing integrations reliable.

The intended resource benefit is concrete: while waiting on CI or another thread, Codex should be able to release the current model turn and consume no further model budget until the registered condition changes.

Start by tracing the App Pause Goal and Resume Goal controls, then compare their owner-state behavior with the app-server thread/goal/set path. Define completion around durable, cancellable one-time wakeups, synchronized owner state, and no continuation before the selected deadline or event; verify behavior across app restarts and external state changes.