Windows Codex app hangs indefinitely during context compaction after `responses/compact` on bundled agent `0.122.0-alpha.1`
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_versionseen 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-d0b0c160d8a72026-04-18 00:07:00local time:POST api.path="responses/compact"appears in logs- No matching compact completion log found
2026-04-18 00:11:44local time: shutdown aborts the running task- Shutdown logs include:
aborting running taskdidn't complete gracefully after 100ms
Affected thread 2
thread_id = 019d9c33-94dc-7bd0-991f-c0321b2ad4382026-04-18 00:51:17local time:POST api.path="responses/compact"appears in logs- No matching compact completion log found
2026-04-18 00:59:18local time: shutdown aborts the running task- Shutdown logs include:
aborting running taskdidn't complete gracefully after 100ms
Additional observations
- I did not find stuck local queue records in the state DB:
jobsstage1_outputsagent_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/compactis 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.
4 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I used AI to build a small local tool for Codex Desktop getting stuck on “Automatically compacting context.” It has helped on my machine, but I can’t guarantee it will work for others. I’m not technical and can’t provide support, only a possible workaround and some ideas. Repo: https://github.com/wangcangshu/codex-desktop-thread-rescue
I have another Windows Codex Desktop compaction case that may help narrow this down. I am not posting raw logs/request bodies, but the request-shape stats are below.
Environment:
10.0.2620026.519.41501gpt-5.5xhighfastObserved timeline (KST):
2026-05-26 21:37:49: last token usage before compact wasinput_tokens=98457,model_context_window=258400(~38.1%).2026-05-26 21:38:19: compact task started.2026-05-26 21:38:19:POST /backend-api/codex/responses/compactwas issued.2026-05-26 21:50:25: user interrupted the still-active compact task.726155 ms(~12.1 min).Sanitized compact request shape:
body_len=456063estimated_bytes=480999input_items=85input_total_string_chars=402197reasoning={"effort":"xhigh"}tools=17message=24compaction=1reasoning=14function_call=20function_call_output=20custom_tool_call=3custom_tool_call_output=351849 message/developer38187 function_call_output37026 message/user33971 function_call_output28578 function_call_output23314 function_call_output22529 function_call_output20134 function_call_output16578 compaction13119 function_call_output11073 reasoningWhy this seems useful:
gpt-5.5,xhigh, full tool schemas, and large raw tool outputs.Hypothesis / ask:
This looks like remote compaction can inherit a normal turn's expensive request shape instead of using a dedicated compaction-safe summarization profile. It may be worth checking whether
/responses/compactshould ignore/reject tool schemas, clamp reasoning effort for compaction, cap raw tool outputs server-side, and enforce deadline/cancellation propagation.I can share more sanitized breakdowns if useful, but I am avoiding raw request bodies/logs because they may contain private workspace content.
Thanks for reporting this problem. Until recently, Codex used a separate endpoint and server-side logic for compaction. We recently switched to a more robust approach where the compaction logic is moved locally using the same endpoint as normal turns. This eliminates "remote compaction" errors and increases the stability and reliability of compaction operations. If you see further problems with compaction, please use
/feedbackand open a new bug report.