Codex Desktop coordinator thread can stay thinking with empty interrupted turn and missing thread tools

Open 💬 2 comments Opened Jun 12, 2026 by jimmycarp966

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

26.609.30741 (build 3808)

What subscription do you have?

ChatGPT Pro subscription, USD 200/month.

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

In Codex Desktop, coordinator/captain style workflows that create, open, or read other Codex threads can intermittently get stuck in "thinking" without executing anything. The turn appears to be accepted, but no tools run and no assistant output is produced. In some cases, the thread-management tools/commands for "hilos" are not available or do not work at all in the affected coordinator flow.

One concrete affected thread:

Thread id: 019ebdd3-092e-7f90-b008-9f93b72a16f9
Thread title: Audita superficies cobranzas
Status after inspection: idle
The only recorded turn was interrupted
Duration: 228644ms
Items/output for that turn: empty (items: [])
Local cwd was a client repo path, redacted here.

From the user perspective this looks like: a captain/coordinator delegates or inspects threads, then the spawned/opened/read thread stays thinking and does not perform any actual work. This happened several times during the afternoon, not just once.

What steps can reproduce the bug?

I do not have a deterministic minimal repro yet, but the repeated real-world flow is:

Use Codex Desktop as a coordinator/captain thread.
Ask it to create, open, inspect, or read other Codex threads ("hilos") as part of a multi-thread operational workflow.
Let the worker/coordinator continue.
Intermittently, the target/current thread accepts the turn but remains thinking, produces no messages, and does not execute any tools.
Interrupting the turn leaves an empty interrupted turn in the thread history.

Observed evidence from read_thread for one affected thread:

{
  "thread": {
    "id": "019ebdd3-092e-7f90-b008-9f93b72a16f9",
    "title": "Audita superficies cobranzas",
    "status": { "type": "idle" }
  },
  "turns": [
    {
      "status": "interrupted",
      "durationMs": 228644,
      "items": []
    }
  ]
}

Related searches before filing found similar but not identical open issues around stuck thinking, subagents, and thread-management tools, including #23292, #23930, #24287, #26354, and #26907.

What is the expected behavior?

When a coordinator/captain thread creates, opens, reads, or delegates to another thread, the resulting turn should either:

start executing normally and show tool calls/output, or
fail quickly with a visible, actionable error explaining why thread-management tools are unavailable or why the thread cannot continue.

It should not remain thinking for several minutes with no tool calls, no assistant message, and no recorded turn items.

Additional information

This is especially disruptive for multi-thread coordination workflows, because the coordinator cannot tell whether the worker is still alive, blocked, missing thread tools, or silently failed. A visible failure state would be much better than an empty thinking turn.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#26354
#26907
#26683

Powered by Codex Action

michaelvd2 · 1 month ago

Additional macOS Desktop evidence supports treating this as a turn-generation lifecycle bug rather than a coordinator prompt failure.

In one app-server-backed coordinator task, three consecutive turns ended as interrupted with error: null. The first ran for about 47 minutes and included compaction plus subagent work. The next two explicit attempts to continue ended after roughly 6–7 seconds without normal assistant/tool work. A reasoning-mode change occurred during the first turn and may have triggered cancellation, but it does not explain why later explicit resumes could not create one clean non-empty generation.

The invariant that would have prevented this cohort is:

Bind every continuation-capable event to {parent_thread_id, parent_turn_id, continuation_generation}.
turn/interrupt atomically terminalizes the parent and invalidates that generation before acknowledgement.
Late child completion, process completion, settings application, wake, or other continuation events against a terminal generation may update status/history only; they must create zero parent turns.
One explicit user resume creates exactly one new generation and one non-empty turn.
Expose a bounded structured interruption reason instead of only interrupted plus error: null.

A useful regression fixture would interrupt one parent with delayed children and one without children, deliver every registered late continuation event, assert zero new turns, then send one explicit resume and assert exactly one non-empty turn.