codex - 💡(How to fix) Fix Windows Codex app hangs indefinitely during context compaction after `responses/compact` on bundled agent `0.122.0-alpha.1` [1 comments, 2 participants]

Summary

On the Windows Codex app, long threads that trigger automatic context compaction can get stuck forever on the compaction state. The UI shows context compression in progress, but the thread never resumes.

From local logs, the app does send POST api.path="responses/compact", but I cannot find a corresponding completion event for the affected threads. The only way to recover is to force-close the window or quit the app, which then aborts the running task during shutdown.

This looks like a compaction pipeline hang or missing completion/return path, not just a fake UI spinner.

Environment

• Product: Codex app for Windows
• OS: Windows
• App package version: OpenAI.Codex 26.415.1938.0
• Bundled agent / cli_version seen in affected threads: 0.122.0-alpha.1
• Local standalone CLI on the same machine: codex-cli 0.120.0
• Time zone: Asia/Singapore
• Report date: April 18, 2026

Actual behavior

• A long thread triggers automatic context compaction.
• The UI remains stuck in the compaction state indefinitely.
• The thread does not continue.
• Closing the window or quitting the app triggers shutdown.
• Shutdown logs show the running task being aborted instead of compaction finishing cleanly.

Expected behavior

• Context compaction should complete and the thread should continue normally.
• If compaction fails, the app should surface a visible error and offer a recovery path instead of hanging indefinitely.

What I found locally

I checked local session logs and SQLite logs/state.

Affected thread 1

• thread_id = 019d9c1e-b65a-7142-ace4-d0b0c160d8a7
• 2026-04-18 00:07:00 local time: POST api.path="responses/compact" appears in logs
• No matching compact completion log found
• 2026-04-18 00:11:44 local time: shutdown aborts the running task
• Shutdown logs include:
  • aborting running task
  • didn't complete gracefully after 100ms

Affected thread 2

• thread_id = 019d9c33-94dc-7bd0-991f-c0321b2ad438
• 2026-04-18 00:51:17 local time: POST api.path="responses/compact" appears in logs
• No matching compact completion log found
• 2026-04-18 00:59:18 local time: shutdown aborts the running task
• Shutdown logs include:
  • aborting running task
  • didn't complete gracefully after 100ms

Additional observations

• I did not find stuck local queue records in the state DB:
  • jobs
  • stage1_outputs
  • agent_jobs
• Those tables were empty at inspection time, so this does not look like a leftover local background job backlog.
• This appears more like the compaction request/response path hangs after responses/compact is initiated.
• I also noticed a version shift:
  • older threads on this machine were using 0.119.0-alpha.28
  • affected recent threads are using 0.122.0-alpha.1
• Because of that, this may be a regression introduced after a recent app/bundled-agent update.

Impact

This makes long-running Windows app threads unreliable, because once the issue appears, the current practical workaround is to force-terminate the window or app and lose the live thread state.

Available evidence

I have local evidence available, including:

• session transcripts under $CODEX_HOME/sessions
• local SQLite logs/state inspection results
• a sanitized local incident report with timestamps and affected thread IDs

I can provide sanitized excerpts if needed.