[Windows][CLI 0.144.3/0.144.4] Long-running concurrent sessions stall after tool calls; rollback to 0.144.1 restores normal operation

Component

Codex CLI on Windows x64, running from PowerShell.

Versions

• Affected: 0.144.3 and 0.144.4
• Known-good workaround: 0.144.1

What issue are you seeing?

After upgrading from 0.144.1, multiple concurrent, long-running Codex CLI sessions intermittently stop making progress immediately after completed tool calls.

In one observed run, four new sessions were started on 0.144.4. One completed normally, while three stopped progressing.

During the stalled state:

• the Codex processes remained alive and responsive;
• CPU usage dropped to approximately zero;
• there was no shell, browser, image-generation, or other child tool still running;
• the session histories stopped receiving new model events for roughly 30–45 minutes;
• the TUI continued to look busy and showed no terminal error;
• a fresh, minimal codex exec request succeeded while the existing sessions were stalled.

Background diagnostics also repeatedly contained:

list_models{refresh_strategy=online}: failed to refresh available models: timeout waiting for child process to exit

Interrupting and reopening an affected session could temporarily unblock it, but the behavior recurred. Pinning the launcher and Windows runtime back to 0.144.1, then resuming the same style of workload, restored smooth concurrent operation.

Steps to reproduce

This is workload-dependent rather than a minimal deterministic reproduction:

1. On Windows, install Codex CLI 0.144.4.
2. Start three or more concurrent, long-running CLI sessions.
3. Let the sessions perform repeated model/tool/model cycles and multiple context compactions.
4. Continue for one to several hours.
5. Observe that some sessions may stop receiving model events after a completed tool call while the process remains alive.
6. Roll back to 0.144.1 and resume the same workload.
7. Observe that the sessions continue normally again.

Expected behavior

After a tool result is returned, Codex should continue sampling, retry with a visible bounded error, or terminate the turn with a clear failure state. It should not remain indefinitely indistinguishable from active reasoning.

Regression evidence

On the same Windows machine, network, workspace type, model settings, and reasoning settings, 0.144.1 previously handled more simultaneous sessions and substantially longer histories without this behavior. The stalls appeared after moving to 0.144.3 / 0.144.4, and disappeared after returning to 0.144.1.

A new-request smoke test also succeeded during the incident, which suggests the account and general service path were still usable while the existing long-running streams were stuck.

Privacy note

No raw session files, logs, screenshots, local paths, project names, session IDs, account details, or private workspace content are attached because they contain sensitive data. Sanitized aggregate diagnostics can be provided if maintainers specify the exact fields needed.

Possibly related

• #18723 — long-running Windows sessions becoming unrecoverable after disconnects
• #24550 — long idle periods with large compacted histories
• #32948 — stalled runs appearing indistinguishable from active work

This report differs in that the strongest local signal is a regression between CLI versions, with no user-visible disconnect error during the stalled turns.