Windows Codex app hangs indefinitely during context compaction after `responses/compact` on bundled agent `0.122.0-alpha.1`

Resolved 💬 4 comments Opened Apr 17, 2026 by jojochou714 Closed Jun 29, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 4 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #17289
  • #17508
  • #17335
  • #17928

Powered by Codex Action

wangcangshu · 4 months ago

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

r2gul4r · 3 months ago

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:

  • Windows 11 Pro x64, version 10.0.26200
  • Codex Desktop 26.519.41501
  • Model: gpt-5.5
  • Reasoning effort: xhigh
  • Service tier: fast

Observed timeline (KST):

  • 2026-05-26 21:37:49: last token usage before compact was input_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/compact was issued.
  • 2026-05-26 21:50:25: user interrupted the still-active compact task.
  • Runtime until interrupt: 726155 ms (~12.1 min).
  • No matching compact completion event was recorded after the compact start.

Sanitized compact request shape:

  • body_len=456063
  • estimated_bytes=480999
  • input_items=85
  • input_total_string_chars=402197
  • reasoning={"effort":"xhigh"}
  • tools=17
  • item counts:
  • message=24
  • compaction=1
  • reasoning=14
  • function_call=20
  • function_call_output=20
  • custom_tool_call=3
  • custom_tool_call_output=3
  • largest item classes by string chars:
  • 51849 message/developer
  • 38187 function_call_output
  • 37026 message/user
  • 33971 function_call_output
  • 28578 function_call_output
  • 23314 function_call_output
  • 22529 function_call_output
  • 20134 function_call_output
  • 16578 compaction
  • 13119 function_call_output
  • 11073 reasoning

Why this seems useful:

  • The hang happened at ~38.1% backend context usage, so it does not look like a simple near-context-limit slowdown.
  • The request reached the compact endpoint; local SQLite/JSONL I/O and transport setup do not appear to explain the 12-minute wait.
  • The compact request appears coupled to the active turn shape: 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/compact should 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.

etraut-openai contributor · 1 month ago

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 /feedback and open a new bug report.