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

[shanayatunk]

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

[github-actions]

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

• Context Compaction Hanging #14346
• Compacting is getting stuck #14342
• Very frequent auto compact and after compact, context windows are nearly full. #14447
• Compaction hangs indefinitely at <16% #14425
• Compaction progress state not clearing in Windows app when compaction task fails (stuck "자동으로 컨텍스트를 압축하는 중") #13659

Powered by Codex Action

[Acture]

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: Acture@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.