Windows: Codex can remain active with no progress after tool or stream boundaries #33090

Summary

On Windows, Codex can intermittently remain in a running/busy state even though no useful work is progressing. During the stall there is no new assistant output, token usage does not appear to change, and no relevant files are being written.

In my case this occurred with multiple model choices and was frequently observed near a tool-result boundary, especially after a tool returned slowly or abnormally. This makes the problem look more like a local transport/finalization or state-propagation issue than continued model reasoning.

Environment

• OS: Windows
• Codex CLI/Desktop: observed on recent releases
• Reproduced across multiple model choices; it does not appear to be specific to one model

Observed behavior

Intermittently:

1. A task starts and progresses normally.
2. The task reaches a tool call or tool-result boundary.
3. The tool returns slowly, returns an error/abnormal result, or appears to have completed.
4. Codex continues to show the task as active.
5. No new assistant output appears for an extended period.
6. Token usage appears unchanged during that period.
7. No relevant files are written.
8. In CLI-style runs, the parent process may remain alive until manually interrupted.

A related CLI symptom was that --output-last-message could remain empty even when useful response content was already visible in stderr, but this was not the main mitigation described below.

Local configuration changes that appeared to help

The largest improvement followed changes to the model transport and response-stream finalization behavior. The relevant provider settings were:

supports_websockets = true
websocket_connect_timeout_ms = 15000
stream_max_retries = 1
stream_idle_timeout_ms = 60000

These settings configure WebSocket capability/connection timeout and put a finite idle limit on an HTTP/SSE response stream that stops producing events. After applying them, the apparent stalls became much less frequent locally.

To be precise, stream_idle_timeout_ms is a response-stream idle timeout, not a timeout for the execution duration of a tool. I did not confirm a separate tool-execution timeout change.

Large local log database

The local Codex log database had also grown to approximately 2.14 GB. After backing it up and cleaning it, its size was approximately 94 MB. Stability appeared to improve after the cleanup, but this is only a correlation; I cannot establish that log size was a root cause.

Expected behavior

• If a tool fails or returns abnormally, the result should be propagated back to the model/runtime so the task can continue or fail clearly.
• If a WebSocket or HTTP/SSE response stream becomes silent, Codex should reconnect, time out, or surface a clear error instead of remaining active indefinitely.
• When model/tool work has completed, completion should reliably propagate to the UI and parent process.

Request

Please investigate the Windows runtime paths around:

• tool-result delivery and abnormal tool returns;
• WebSocket connection/fallback behavior;
• HTTP/SSE stream idle detection and finalization;
• UI/parent-process state propagation after a tool or stream boundary;
• performance or state-propagation effects when the local log database becomes very large.

I am not claiming the local settings or log cleanup identify the definitive root cause. They are the changes most closely associated with the improvement I observed.