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.
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
OpenAI.Codex 26.415.1938.0cli_versionseen in affected threads:0.122.0-alpha.1codex-cli 0.120.0Asia/SingaporeApril 18, 2026Actual behavior
Expected behavior
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 logs2026-04-18 00:11:44local time: shutdown aborts the running taskaborting running taskdidn't complete gracefully after 100msAffected thread 2
thread_id = 019d9c33-94dc-7bd0-991f-c0321b2ad4382026-04-18 00:51:17local time:POST api.path="responses/compact"appears in logs2026-04-18 00:59:18local time: shutdown aborts the running taskaborting running taskdidn't complete gracefully after 100msAdditional observations
jobsstage1_outputsagent_jobsresponses/compactis initiated.0.119.0-alpha.280.122.0-alpha.1Impact
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:
$CODEX_HOME/sessionsI can provide sanitized excerpts if needed.