Codex Desktop: exec cell hangs for 3,806s after nested shell completed in 0.2s; timeout/yield did not return control #33036

Summary

On Codex Desktop for Windows, a code-mode exec cell failed to yield or close for about 3,806.8 seconds even though the nested local shell command completed successfully in about 0.2 seconds.

The nested shell_command had timeout_ms: 10000. After the outer cell finally returned Script running with cell ID ..., an immediate wait reported the cell as already completed.

This left the user waiting for roughly one hour with no model control, progress update, timeout error, or cancellation opportunity.

Environment

• Product: Codex Desktop
• Codex package: OpenAI.Codex 26.707.9981.0
• Platform: Windows x64
• Windows version/build: 10.0.26200
• Local workspace access: unrestricted
• Date: 2026-07-14
• Exact local paths, project names, thread IDs, account identifiers, and prompt contents intentionally omitted

Sanitized event sequence

The outer call used code-mode exec and awaited a nested local shell command:

exec starts
  -> shell_command(
       local PowerShell filesystem cleanup + verification,
       timeout_ms = 10000
     )

... no model-visible return or progress for about 3,806.8 seconds ...

exec returns:
  Script running with cell ID <redacted>
  Wall time 3806.8 seconds

wait(cell_id=<redacted>, yield_time_ms=1000) returns immediately:
  Script completed
  nested shell exit code: 0
  nested shell wall time: about 0.2 seconds

The local operation touched only a few small generated cache directories and had no network dependency. The subsequent result shows the nested process itself was not running for an hour.

Expected behavior

At least one of the following should have happened:

1. The outer exec should have yielded after its normal short yield interval.
2. The nested shell_command should have returned or timed out around its configured 10-second deadline.
3. If completion propagation failed, Codex should have emitted a visible recoverable error and returned control to the model/user.
4. The user should always retain a working cancellation path.

An already-completed nested tool must not leave the outer cell silently pending for an unbounded period.

Actual behavior and impact

• No progress event reached the model for about one hour.
• The model could not inspect, cancel, or notify the user while blocked.
• The configured nested timeout did not provide an effective upper bound.
• When control returned, the cell was already complete.
• This makes ordinary local tool calls capable of causing unbounded user-visible hangs.

Reproduction status

Observed once in a real Codex Desktop task. I have not deliberately repeated the one-hour hang because doing so would impose significant user cost. The timing evidence above comes from the tool-call results recorded in the affected turn.

Related issues

• [URGENT] Stable IDE extension ships a prerelease CLI with under-development "Code mode" silently active, breaking any long-running MCP calls and burning tokens while waiting #29122 — related code-mode exec / wait lifetime and token/control semantics, but its reported nested MCP operation was intentionally long-running. In this case, the nested local shell command had already completed in about 0.2 seconds.
• Codex Desktop can remain in Thinking after successful tool calls with no streamed follow-up or a hung /responses request #24850 — related Codex Desktop stale Thinking state after successful tool calls, but this report specifically shows a running cell returned only after a 3,806.8-second outer delay and then completed immediately on wait.

Requested investigation

Please check the boundary between:

1. nested tool completion,
2. code-mode cell yield/closure,
3. completion notification delivery to the turn runner, and
4. timeout enforcement.

A hard watchdog should return control even if completion notification propagation fails.