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

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:

1. Use Codex Desktop as a coordinator/captain thread.
2. Ask it to create, open, inspect, or read other Codex threads ("hilos") as part of a multi-thread operational workflow.
3. Let the worker/coordinator continue.
4. Intermittently, the target/current thread accepts the turn but remains thinking, produces no messages, and does not execute any tools.
5. 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.