[Windows][CLI 0.146.0] app-server queue saturation precedes silent exit to PowerShell

Summary

Codex CLI 0.146.0 intermittently exits without an error and returns directly to the PowerShell prompt during long, tool-heavy sessions.

Windows Terminal and PowerShell remain open. Only the Codex process ends. No panic, crash dump, Windows application fault, or out-of-memory condition is recorded.

One incident was immediately preceded by severe in-process app-server/TUI event-queue saturation. I am reporting this as a correlation, not claiming it is the proven termination cause.

### Environment

• Codex CLI: 0.146.0
• Installation: global npm package @openai/codex
• OS: Windows 11, build 10.0.26200
• Shell: PowerShell in Windows Terminal
• Model: Sol, ultra reasoning
• One user-visible terminal and Codex session
• Codex had been reinstalled and updated to the latest stable release
• Incident date: July 31, 2026, PDT

### Observed behavior

Codex abruptly returned to PowerShell at approximately:

• 3:40 PM
• 4:19 PM
• 4:40 PM
• 6:36 PM

The affected sessions had approximately 194k to 247k accumulated tokens and involved long-running, tool-heavy work with frequent progress, tool-output, and diff events.

There was no visible error message before Codex exited.

### Queue-saturation incident

At 4:40:20 PM, Codex logged 448 instances of:

dropping in-process app-server event because consumer queue is full

Those warnings occurred within approximately 148 milliseconds.

They were followed by:

app-server event consumer lagged; dropping ignored events skipped=530

and another event with:

skipped=3

The final Codex log entry occurred approximately 26.4 seconds after the first queue-full warning, at about 4:40:47 PM. Codex then returned to PowerShell.

No panic, fatal error, OOM, interrupt, shutdown, or process-exit marker was recorded.

### Other incidents

The other exits did not have operational queue-full or consumer-lag warnings in their surrounding log windows.

Two earlier queue-saturation bursts also did not terminate Codex:

• 149 queue-full warnings, followed by at least 74 seconds of continued logging
• 49 queue-full warnings, followed by at least 369 seconds of continued logging

Therefore queue saturation does not appear to be invariably fatal, but the 4:40 burst was substantially larger and closely preceded the exit.

### Feedback failure

A later short Codex session was opened to diagnose this problem and submit /feedback.

That Codex process also exited unexpectedly while displaying Working (14s), before the feedback could be submitted. That session did not contain genuine queue-saturation warnings.

### Additional process-lifecycle observation

Codex state records contained other independently labeled cli/user roots whose logging ended within seconds of the affected process during several incidents.

They were not labeled as Codex collaboration subagents. I only had one user-visible terminal/session running, so their launch origin is unknown. They may have been background or tool-launched processes.

This suggests a shared process-lifecycle, process-group, or external termination mechanism may also need investigation.

### Negative findings

I found no:

• Codex panic
• fatal log entry
• Windows Error Reporting crash dump
• Reliability Monitor failure
• relevant Windows application-event fault
• low-memory condition
• database-integrity failure
• unretried terminal network failure

The Codex state and log databases passed integrity checks.

The databases do not record the Codex CLI process exit code or termination reason, so they cannot distinguish a graceful return, external termination, or unlogged internal error.

### Expected behavior

If the TUI consumer falls behind, Codex should recover, coalesce or drop nonessential events, or display a controlled error.

It should not silently terminate the CLI process.

If termination is unavoidable, Codex should persist and display the exit reason.

### Public-source observation

In the 0.146.0 source:

• The relevant in-process queues have capacity 128.
• The queue-full branch increments skipped events and returns Continue.
• The lagged-event handler logs the condition but does not request exit.
• Channel closure is handled separately.
• The lower and upper queue layers disagree about which events require lossless delivery.

I could not identify a direct public-code path from:

queue full -> lagged -> process exit

This makes an indirect consumer-task failure, cancellation, channel-boundary failure, or separate lifecycle mechanism possible but unproven.

### Requested investigation

Please investigate:

1. Whether severe in-process app-server/TUI backpressure can indirectly cancel or terminate an event-consumer task.
2. Whether consumer or app-server channel closure can reach an unlogged TUI exit path.
3. Every path that allows the native CLI to return without persisting an exit reason.
4. The lower-versus-upper must-deliver event-classification mismatch.
5. The near-synchronous termination of independently labeled CLI roots.
6. A stress test with a deliberately slow TUI consumer and bursts exceeding both 128-event queues.

### Related issues

• https://github.com/openai/codex/issues/34037
• https://github.com/openai/codex/issues/35341
• https://github.com/openai/codex/issues/36005
• https://github.com/openai/codex/issues/34711
• https://github.com/openai/codex/issues/20777
• https://github.com/openai/codex/issues/20601

I can provide redacted log extracts, timestamps, process UUIDs, and session IDs if needed. I do not want to upload the complete databases or raw session transcripts publicly because they may contain
sensitive project content.