Codex Desktop create_thread can leave child task inProgress with zero events indefinitely

What version of the Codex App are you using?

• ChatGPT/Codex Desktop: 26.707.72221 (build 5307)
• Child session cli_version: 0.144.2

What platform is your computer?

• macOS 15.7.7 (24G720)
• Apple Silicon

What issue are you seeing?

Codex Desktop's official create_thread tool successfully returned a child task ID, but the child remained inProgress without ever producing an assistant message, reasoning event, tool call, status update, or error.

Affected child task:

019f63aa-58be-7851-be4a-992330130a80

The child was created for a bounded infrastructure benchmark in a saved local project. Its prompt asked it to test software on an existing remote SSH host, but the child never progressed far enough to inspect the workspace, connect remotely, request approval, or run any command.

The parent-side create_thread call returned normally after approximately 5.2 seconds:

{"threadId":"019f63aa-58be-7851-be4a-992330130a80"}

A subsequent read_thread showed:

{
  "status": {"type":"active"},
  "turns":[{
    "status":"inProgress",
    "items":[]
  }]
}

Local child rollout evidence:

• Session created: 2026-07-15T02:45:36Z
• task_started: 2026-07-15T02:45:41Z
• No response items or tool calls followed.
• User interruption: 2026-07-15T03:57:29Z
• Recorded turn duration: 4,308,463 ms (about 71 minutes 48 seconds)
• The initial turn ended only because the user manually interrupted it.

Before interruption, the child rollout effectively contained only:

1. session_meta
2. task_started

There was no model-visible error and no indication of whether the stall was in model dispatch, child initialization, tool setup, or task scheduling.

What steps can reproduce the bug?

This is a concrete occurrence rather than a deterministic minimal reproduction:

1. In Codex Desktop, use the official create_thread tool.
2. Target an existing saved local project with environment: { type: "local" }.
3. Use the configured default model with high reasoning.
4. Give the child a self-contained task.
5. create_thread returns a valid threadId.
6. Inspect the child with read_thread.
7. Observe that it remains active / inProgress with items: [] indefinitely.
8. Manually interrupt the child after more than an hour.

What is the expected behavior?

After create_thread returns a registered child task:

• The child should begin producing model/tool events promptly, or
• Transition to a structured startup error within a bounded timeout.
• A task that has emitted no first event should expose a useful state such as queued, dispatching, startup_failed, or model_request_pending, rather than appearing generically inProgress.
• The Desktop UI and read_thread should provide enough diagnostics to distinguish a queued task from a dead/stalled one.

Additional information

This appears adjacent to, but distinct from:

• #24951: spawn_agent itself blocks before returning an agent ID. Here, create_thread returned a valid child ID promptly.
• #24389: unresponsive child plus a later close_agent hang. Here, no close operation was involved.
• #26822: children run or shut down without delivering results. Here, the child rollout contains no evidence that model execution ever began.

The exact failure boundary looks like: child task registration succeeded, but first-turn execution never produced an event.

Private workspace paths, remote host details, and benchmark contents are omitted.