Windows Codex App: Frequent hanging on 'Automatically compacting context' every 1-2 minutes + indefinite freeze

Resolved 💬 2 comments Opened Mar 12, 2026 by shanayatunk Closed Jul 2, 2026

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.306.966.0

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Same issue here on Windows desktop app (Codex version: [your version from About menu], Plus subscription).

"Automatically compacting context" triggers extremely often — every 1-2 minutes or after small/medium requests, even when context usage is low initially.
It frequently hangs indefinitely (5–30+ minutes, spinner stuck, app unresponsive — have to kill via Task Manager).
Using GPT-5.4 with High.
Happens on large-ish codebases/projects.
Workarounds like switching to CLI for compaction then restarting app help temporarily, but it's disruptive.

This started/recently worsened around March 11–12. Please prioritize — it's making long sessions unusable.

Steps to repro: Start thread → add some code/files → make a few planning/refinement requests → compaction triggers often and hangs.

What steps can reproduce the bug?

Probably a longer chat

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 5 months ago

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

#14346
#14342
#14447
#14425
#13659

Powered by Codex Action

Acture · 5 months ago

I did some root-cause analysis on this.

Neither inline nor remote compaction has timeout protection:

compact.rs: drain_to_completed() loops on stream.next().await with no timeout — if the model API stalls, the await never resolves and the retry loop is never reached.
compact_remote.rs: compact_conversation_history() has the same issue.

CodexErr::Timeout already exists and is_retryable() returns true for it, so wrapping both calls with tokio::time::timeout() lets the existing retry-with-backoff loop handle it gracefully — the user sees "Reconnecting..." instead of an infinite freeze.

Prepared a fix (Acture:fix/compaction-timeout-14472):

Wrap drain_to_completed() and compact_conversation_history() with 120-second tokio::time::timeout()
On timeout, return CodexErr::Timeout to trigger existing retry logic

Commit: https://github.com/Acture/codex/commit/f481f5f (includes a unit test verifying timeout produces a retryable CodexErr::Timeout)

Patch (for easy cherry-pick):

@@ compact.rs @@
+use std::time::Duration;
+use tokio::time::timeout;
+
+pub(crate) const COMPACTION_TIMEOUT: Duration = Duration::from_secs(120);

-        let attempt_result = drain_to_completed(
-            &sess,
-            turn_context.as_ref(),
-            &mut client_session,
-            turn_metadata_header.as_deref(),
-            &prompt,
-        )
-        .await;
+        let attempt_result = match timeout(
+            COMPACTION_TIMEOUT,
+            drain_to_completed(
+                &sess,
+                turn_context.as_ref(),
+                &mut client_session,
+                turn_metadata_header.as_deref(),
+                &prompt,
+            ),
+        )
+        .await
+        {
+            Ok(inner) => inner,
+            Err(_elapsed) => Err(CodexErr::Timeout),
+        };

Verified locally: all 50 compact tests pass. just fix -p codex-core reports no warnings.