Codex Desktop restart promotes queued follow-up ahead of incomplete active goal

What version of the Codex App are you using (From “About Codex” dialog)?

Codex Desktop 26.721.3996.0 (Microsoft Store/AppX, x64).

What subscription do you have?

Not included in this public report.

What platform is your computer?

Windows, x64.

What issue are you seeing?

After updating and restarting Codex Desktop while a long-running task was still incomplete, Codex resumed the same thread but promoted a queued follow-up task into the active run ahead of the unfinished task.

The original task had a persistent active goal and no completion event. On restart, goal-continuation context was restored correctly, but the queued follow-up was delivered in the same new run and the agent began planning that later task instead of continuing the active goal. The user had to correct the agent twice and explicitly restate that the queued task must run only after the unfinished task completes.

This is an ordering/arbitration failure between:

1. recovery of an incomplete active goal after an app restart, and
2. a follow-up that the user queued specifically for execution after the current task.

The queued message was not lost. It was promoted too early.

Observed timeline

Time zone: UTC+07:00.

• 19:50:16: updated Codex Desktop process started.
• 19:50:26: the same thread began a new task/run after restart.
• The recovered turn contained both the still-active goal-continuation context and the later queued instruction.
• The agent immediately started reconciling/planning the queued instruction.
• Within about one minute, the user had to state that the previous task was not finished.
• The user then had to explicitly restate that the queued task must not run until the previous task is fully complete.

Read-only local rollout metadata confirms that the original task had no terminal completion before the restart. The active goal was still present after restart. Exact task IDs, local paths, prompt content, business data, and logs are intentionally omitted from this public issue and can be supplied privately if maintainers need them.

What steps can reproduce the bug?

1. Start a long-running Codex Desktop task that has a persistent active goal and is still doing tool work.
2. While it is running, submit a separate follow-up using Queue, with the intent that it should run only after the active task finishes.
3. Update or fully quit and restart Codex Desktop before the active task completes.
4. Reopen/resume the same thread.
5. Observe the first recovered run.
6. In the failing case, Codex restores the incomplete goal but also delivers the queued follow-up as active input, and the agent starts the queued task before completing the original one.

What is the expected behavior?

• An incomplete active goal should resume first after restart.
• A queued follow-up should remain queued, in its original order, until the active goal reaches a terminal state.
• Restart/recovery must not reinterpret Queue as Steer or as the primary instruction for the recovery run.
• If recovery cannot determine the correct ordering, the UI should preserve both items and ask the user rather than silently promoting the later task.

Impact

This can derail long-running work, mutate the wrong plan, start external actions in the wrong order, and force the user to manually reconstruct task precedence after every restart/update.

Related but not exact duplicates

• #32715 — queued follow-ups are lost after restart. Here the follow-up survives but runs too early.
• #26413 — queued follow-ups remain persisted but stop processing. Here processing occurs, but before the incomplete active goal.
• #34026 — stale completed/streaming UI state traps follow-ups. Here the goal is genuinely incomplete and recovery ordering is wrong.

No secrets, project content, account email, raw local paths, or full logs are included.