Codex Desktop: interrupted tool task becomes an orphaned “thinking” turn and stop instruction never completes

No files, tests, or entry points are named in the report. Start by reproducing the interrupted-task and follow-up stop behavior in Codex Desktop, then trace the active-turn and cancellation flow. Done means interrupted turns settle visibly, stop instructions do not orphan a new turn, and stale or waiting states are distinguishable.

Summary

Codex Desktop can leave a thread in an unusable state after interrupting a long-running task. The original work is interrupted, but a follow-up “stop” instruction creates a new in-progress turn that can remain stuck indefinitely on “Thinking” without producing a reply or running a visible tool call.

This is especially risky when the interrupted task was performing an external write.

Environment

• Product: Codex Desktop
• Platform: macOS (Apple Silicon)
• Observed in a local project thread

What happened

1. A task was preparing and uploading a draft to an external API.
2. The external system showed that the draft already existed, while Codex still showed the task as running.
3. I sent a clear follow-up instruction: stop immediately; do not upload, retry, create, or modify anything further.
4. The original turn was marked as interrupted.
5. Codex then created a new in-progress turn for the stop instruction itself.
6. That new turn remained on “Thinking” and did not return even a simple confirmation that it had stopped.

The thread had already accumulated several interrupted turns and failed image-editing attempts, but the final stop instruction was simple and should not have required expensive context recovery.

Why this is a serious problem

• The UI does not distinguish model reasoning, waiting for an external network request, cancellation propagation, and a stale/orphaned state.
• A user cannot reliably tell whether it is safe to interrupt.
• If an external write request has an unknown outcome, the agent may retry it, creating duplicate external resources.
• “Send and steer” / stop instructions do not reliably take control of a stuck turn.

Expected behavior

1. Interrupt should immediately settle the active turn as cancelled in the UI.
2. A stop instruction should cancel or supersede the active operation, not become another indefinitely running turn.
3. External write operations should be idempotent by default: after an unknown result, query for the expected result before any retry.
4. The UI should clearly show whether a turn is:
   • reasoning,
   • waiting for a tool/network request,
   • cancelling,
   • interrupted,
   • or stale/orphaned.
5. Long-running image/tool requests should have clear timeouts and actionable error states.

Reproducibility

I observed this repeatedly in the same Desktop thread:

• precise image-edit requests stalled or failed after a long wait;
• interrupted/resumed turns displayed “Thinking” without progress;
• an external draft-creation task remained active after the external side already contained the expected result;
• a follow-up stop command itself became stuck as a new in-progress turn.

No secrets, account identifiers, or external API credentials are included here.