Issue Station
Sign In
Tools hereToolbox

codex - 💡(How to fix) Fix Codex CLI TUI can remain stuck after completed turn when in-process notification queue is full on Windows [2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#20777•Fetched 2026-05-03 04:45:40
View on GitHub
Comments
2
Participants
2
Timeline
8
Reactions
0
Author
zmc0218zmc0218
Participants
github-actions[bot]github-actions[bot]zmc0218zmc0218
Timeline (top)
labeled ×5commented ×2closed ×1

Error Message

WARN codex_app_server::in_process: dropping in-process server notification (queue full)

Code Example

C:\Users\<user>\.codex\sessions\YYYY\MM\DD\rollout-<timestamp>-<id>.jsonl

---

WARN codex_app_server::in_process: dropping in-process server notification (queue full)
RAW_BUFFERClick to expand / collapse

What happened?

Codex CLI interactive TUI remains stuck/running after the task has actually completed.

The final assistant answer is persisted in session history. After closing and reopening Codex history, the completed result is visible. However, the live PowerShell/Windows Terminal TUI does not render the final result or return to a completed state.

Environment

  • Codex CLI: 0.128.0
  • OS: Windows 11
  • Shell: PowerShell 7.6.1
  • Terminal: Windows Terminal
  • Working directory: Windows mapped drive, e.g. V:\path\to\large-repo
  • Backing path: UNC/network share, e.g. \\<server>\<share>\path\to\large-repo
  • Node: v24.12.0
  • Install method: npm global @openai/codex

Reproduction pattern

  1. Start Codex CLI interactively with codex.
  2. Work inside a large repository on a Windows mapped drive.
  3. Run a long/complex task with multiple shell/MCP/tool calls.
  4. The task completes and final answer is written to session history.
  5. The live TUI remains stuck and does not show the final answer.
  6. Reopening Codex history shows that the task was completed.

Evidence

Session history contains final assistant message and task_complete.

Example sanitized path:

C:\Users\<user>\.codex\sessions\YYYY\MM\DD\rollout-<timestamp>-<id>.jsonl

The Codex TUI log contains many queue-full warnings around the completion window:

WARN codex_app_server::in_process: dropping in-process server notification (queue full)

Observed count: over 100 such warnings near the final completion time.

Expected behavior

Even if intermediate streaming/progress notifications are dropped under backpressure, the final assistant output and completed turn state should be delivered reliably to the TUI.

The TUI should not remain stuck once the turn is completed and persisted.

Actual behavior

The turn completes and is persisted, but the live TUI does not reliably render the final output or transition to a completed state.

Suspected cause

The in-process app-server notification queue can become full. Some notifications are dropped. TurnCompleted appears to be treated specially, but the final assistant message and/or final TUI state refresh may still be lost or not rendered, leaving the interactive UI stuck.

Relevant source area

  • codex-rs/app-server/src/in_process.rs
  • codex-rs/app-server/src/transport/mod.rs

extent analysis

TL;DR

The Codex CLI interactive TUI may be stuck due to a full in-process app-server notification queue, causing dropped notifications and unreliable rendering of the final output.

Guidance

  • Investigate the codex-rs/app-server/src/in_process.rs and codex-rs/app-server/src/transport/mod.rs source areas to understand how the notification queue is handled and how TurnCompleted notifications are treated.
  • Check the Codex TUI log for patterns or correlations between the queue-full warnings and the task completion time to better understand the timing and frequency of dropped notifications.
  • Consider increasing the notification queue size or implementing a more robust handling mechanism for TurnCompleted notifications to prevent them from being dropped.
  • Verify that the final assistant output is correctly written to the session history and that the issue is indeed related to the TUI rendering, rather than a problem with the task completion itself.

Example

No code snippet is provided as the issue does not contain sufficient information to create a specific example.

Notes

The suspected cause is related to the in-process app-server notification queue becoming full, but the exact mechanism and solution may require further investigation and debugging.

Recommendation

Apply a workaround, such as increasing the notification queue size or implementing a retry mechanism for dropped notifications, as the root cause is related to the queue handling and not a simple version upgrade issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Even if intermediate streaming/progress notifications are dropped under backpressure, the final assistant output and completed turn state should be delivered reliably to the TUI.

The TUI should not remain stuck once the turn is completed and persisted.

#cache error#pipeline error#runtime error#dependency conflict#environment setup

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING