[Windows app] Setting a goal mid-run makes the UI appear finished while the previous task keeps running above the goal UI

What version of the Codex App are you using?

Windows package version: 26.903.8094.0 (read from the installed OpenAI.Codex package, not the About dialog).

What subscription do you have?

ChatGPT Pro (20x).

What platform is your computer?

Windows 11 x64 — Microsoft Windows NT 10.0.26200.0.
UI language: Chinese. The active task uses GPT-6 Astra with High reasoning.

What issue are you seeing?

Setting a Goal while an agent is already executing an ordinary task puts the desktop app into a confusing state where the active run, goal lifecycle, cancellation controls, and displayed conversation appear out of sync.

Observed symptoms:

• The original agent task keeps running. Attempts to cancel/stop it do not give the user effective control in this state.
• The newly set goal's timer continues counting, but the goal does not appear to execute.
• There is no visible option to interrupt the current run and prioritize the goal (no “jump the queue” / steering control).
• Canceling the goal does not recover control over the existing task; the user still has to wait for the earlier task to finish.
• The original main agent continues refreshing its existing conversation in the screen area physically ABOVE the goal input/dialog area. Its output is not being inserted into the goal dialog itself. The UI appears to have transitioned as though the previous task had already finished, while that task is actually still running and producing updates above the goal UI. This is an observed UI/runtime-state mismatch, not a confirmed output-routing bug.

This is happening during a real long-running coding task with subagent activity. These are user-observed UI symptoms; I have not established an internal cause or a reproduction frequency.

What steps can reproduce the bug?

1. Start a normal coding task in the Codex desktop app and let the main agent continue executing tools/work.
2. Before that task finishes, enter another request and use the Goal feature (“设为目标” / “Set as goal”) to set it as a goal.
3. Observe the goal timer, the original task's output, and the available stop/interrupt/steering controls.
4. Try stopping/canceling the ongoing work, then cancel the goal.
5. Observe that the original task continues updating the existing conversation physically above the goal input/dialog area. The UI looks as though the previous task has ended, but execution has not ended; goal execution does not visibly begin.

What is the expected behavior?

• Creating a goal during an active run should have an explicit, consistent state: queued, actively running, or waiting for the current run.
• If it is queued, the UI should say so and distinguish waiting time from actual goal execution time.
• The user should retain a working stop/cancel control, and have a clear way to interrupt/steer the current task when changing priorities.
• Canceling the goal should stop its timer and restore a coherent normal-task view without orphaned running state.
• The UI should continue to represent the original task as running until it actually stops or finishes. It should not transition to an apparently finished/new-goal state while the previous conversation is still actively refreshing above the goal input area.

Additional information

A screenshot of the affected desktop conversation was provided while reporting this. It shows ongoing main/subagent task updates and the “设为目标” affordance. The timer and cancellation behavior above are based on the user's interaction, not inferred from a static screenshot. The image is not attached here because this report was submitted through GitHub CLI, which does not directly upload issue image attachments.

Possibly related: #28104 describes goal/interrupt state becoming inconsistent in the CLI. This report concerns the Windows desktop app, specifically creating a goal while an existing normal agent run is already active, plus an apparent UI/runtime lifecycle mismatch and missing priority controls. I have not verified whether they share a cause.

Reproduce this on the Windows desktop app by starting a normal coding task, setting a goal before it finishes, and checking the timer, conversation updates, and stop or cancel controls. Compare the lifecycle symptoms with the possibly related CLI issue #28104. Done means the UI clearly distinguishes queued, running, and finished states, preserves effective cancellation, and does not appear finished while the original task remains active.