Codex Desktop 0.144.0-alpha.4: agent-created project session stalls on first turn after emitting only reasoning

What version of the Codex App are you using?

Codex Desktop / local CLI metadata from the affected rollout:

• cli_version: 0.144.0-alpha.4
• originator: Codex Desktop
• source: vscode
• thread_source: subagent
• model_provider: openai
• model in turn context: gpt-5.6-sol
• platform: Windows, PowerShell workspace shell
• sandbox: danger-full-access
• approval policy: never

I do not have the exact desktop build number from the rollout metadata.

What issue are you seeing?

An agent-created project session can stall on the first turn before any local tool command is invoked. The UI appears to be stuck in the model/thinking phase for a long time. Local rollout logs show that the session received the user message and later wrote exactly one reasoning response item, but did not proceed to commentary, tool calls, shell commands, git checks, or task completion.

This is a regression in practice: prior Codex versions did not commonly get stuck at the very first turn for this workflow, while the current version is causing similar hangs across many newly created sessions.

Reproduction context

The session was created by another Codex task using the Codex app thread-creation flow for a local project workspace. It was intended to be a visible project development session with a long initial task prompt.

Sanitized local session metadata:

session_id: 019f5ab3-2ab3-7da3-b727-f5646b23bac6
cwd: D:\ai\ullwin-product-display
cli_version: 0.144.0-alpha.4
originator: Codex Desktop
source: vscode
thread_source: subagent
model_provider: openai
model: gpt-5.6-sol

Local evidence from rollout log

The affected local rollout file was:

C:\Users\PC\.codex\sessions\2026\07\13\rollout-2026-07-13T16-58-44-019f5ab3-2ab3-7da3-b727-f5646b23bac6.jsonl

Relevant event sequence, sanitized:

2026-07-13T08:58:49.663Z  session_meta       session created
2026-07-13T08:58:49.663Z  event_msg          task_started
2026-07-13T08:58:59.297Z  turn_context       turn_id=019f5ab3-3f63-7302-8578-751ac2a1543e
2026-07-13T08:58:59.303Z  response_item      user message recorded
2026-07-13T08:58:59.303Z  event_msg          user_message
2026-07-13T09:00:40.040Z  response_item      reasoning only
2026-07-13T10:04:46.127Z  event_msg          thread_settings_applied / later restart or resume
2026-07-13T10:04:46.134Z  event_msg          task_started

Between 08:58:59 and 10:04:46, the rollout contains no custom_tool_call, no function_call, no shell_command, no apply_patch, no git command, and no task_complete for the first turn.

The first local tool calls only appeared after the later restart/resume sequence, not during the original first turn.

Steps to reproduce

1. Use Codex Desktop on Windows with codex-cli 0.144.0-alpha.4.
2. From an existing Codex task, create a new local project task/session with a long initial project-development prompt.
3. Let the new session start normally.
4. Observe that the first turn may emit only a reasoning item and then stop producing visible progress.
5. Inspect the local rollout JSONL and verify that no tool calls were made during the stuck first turn.

Expected behavior

The first turn should either:

• proceed to normal assistant output or tool calls;
• fail with a visible error;
• time out with a recoverable diagnostic state; or
• clearly report that it is waiting on model/backend/compaction.

It should not silently stall after a single reasoning item with no local tool activity and no actionable UI state.

Actual behavior

The session appeared stuck in the first turn. Local logs show the model/response pipeline stopped after a reasoning response item, before any local command or tool execution. The user had to abandon or restart/resume the session.

Why this seems like an orchestration regression

The local project code was not reached. No shell command, git command, test command, MCP call, or filesystem operation ran during the stuck first turn. That makes the likely failure point the Codex app/session orchestration, model streaming, first-turn scheduling, or subagent/thread startup path rather than the target repository.

The issue also correlates with current agent-created sessions and long first prompts. It is occurring frequently enough to make multi-session workflows unreliable.

Suggested diagnostics to expose

It would help if Codex surfaced one of these states in the UI and/or rollout logs:

• model stream still active vs disconnected;
• first-turn scheduler waiting state;
• context-compaction/preprocessing status;
• last successful backend event timestamp;
• reason for no tool-call progression;
• automatic timeout/retry when only a reasoning item has been produced for several minutes.

Privacy note

I intentionally did not include the full original user prompt or encrypted reasoning payload because the prompt contained project-specific instructions. The event sequence above is enough to show that the first turn stalled before any local tool execution.