CLI turn remains working but stops emitting events after tool calls

What version of Codex are you using?

Codex CLI 0.149.0

What platform is your computer?

macOS 26.6.1, arm64

What issue are you seeing?

An in-flight CLI turn can remain visibly working while it stops producing assistant output, tool calls, file changes, or other observable progress.

This occurred in two separate GPT-5.6 Luna sessions with xhigh reasoning on the same day, and one affected session stalled twice:

• The turn first made several successful tool calls, then remained silent for more than 9 minutes immediately before a promised edit.
• Pressing Esc ended only the stalled turn and preserved the session.
• Resuming the same session produced one successful file edit, then the turn again remained silent for more than 5 minutes before the next promised step.
• A separate session earlier that day remained silent for more than 20 minutes with the same visible working state.
• In the earlier incident, the process remained alive and had no active child shell/editor process. Esc again restored control and preserved resumability.

This appears different from a legitimately long-running shell command: no tool call was active, no new transcript event appeared, and no file changed during the silent interval.

What steps can reproduce the bug?

The failure is intermittent:

1. Start Codex CLI with GPT-5.6 Luna and xhigh reasoning.
2. Give it a multi-step repository task that includes read-only inspection followed by edits.
3. Allow several tool calls to complete successfully.
4. In some turns, Codex announces the next step but emits no further event while the UI continues to show working.
5. Press Esc.
6. Resume the same session. It may continue successfully, but it can stall again later in the same session.

What is the expected behavior?

An active turn should either continue emitting progress/tool events, complete, or surface a terminal error. If the model stream or internal turn state becomes idle/stuck, the CLI should detect that condition and return control without requiring an unbounded external timeout.

Esc/resume should remain safe, but it should not be the only way to recover.

Additional information

• The incidents occurred in ordinary interactive PTY sessions.
• Existing work and session context remained intact after Esc.
• No repository name, working-directory path, prompts, code, session/thread IDs, host identity, network details, raw logs, or stack samples are included.
• No diagnostic logs are attached because they may contain project context.
• Related reports found during duplicate search describe worker exit (#21937), apply_patch itself stalling (#33719), or Desktop first-output stalls (#24260). In this case the CLI process remained alive and the silence began between tool calls, including after one successful edit.