Compacting is getting stuck

Open 💬 7 comments Opened Mar 11, 2026 by nstas

💡 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)?

Version 26.305.950 (863)

What subscription do you have?

Pro

What platform is your computer?

Darwin 22.5.0 arm64 arm

What issue are you seeing?

"Automatically compacting context" taking 20+ minutes and happen to often.

What steps can reproduce the bug?

Start working, initiate planning, after ONE task done, compacting is being initiated automatically.

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 4 months ago

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

#14120
#13279
#13946
#13815

Powered by Codex Action

RiddleMeThis3 · 4 months ago

Following up to say that lowering to high fixed it.

geokal · 4 months ago

me too!!

teneko · 4 months ago

I face it very often. It is annoying. I have to open codex cli and let it compact the thread, then I need to restart codex app, because otherwise it does not see the updated thread, and then finally I can continue in in the codex app. 🥲

I also notice, that compacting in codex app takes MUCH longer than in codx cli. I use gpt-5.4 xhigh.

MovGP0 · 4 months ago

Context compaction works in the Codex CLI for me, but always have the problem with the Codex GUI on Windows.

twentyOne2x · 4 months ago

Adding a concrete desktop-app example here because this looks like the same failure mode, but with stronger thread-level evidence.

Environment:

Codex App version: 26.309.31024
Platform: macOS 26.3 arm64
Subscription: Pro
Thread: 019cb41c-0825-7f03-82ca-470891d7a6e8

What happened:

The app appeared to get stuck in a long context-compaction / reread loop.
It kept rereading the same small set of files after compaction instead of making clear progress.
I eventually stopped it manually.

Concrete timings from local rollout/log inspection on 2026-03-12:

Turn 1: 14:46:30.440Z -> 17:47:09.463Z, runtime 3h 0m 39s, 110 actual compactions
Turn 2: 17:47:29.644Z -> 18:32:31.318Z, runtime 45m 1.7s, 39 actual compactions
Turn 3: 18:36:30.021Z -> 18:38:06.605Z, runtime 1m 36.6s, 1 actual compaction before I interrupted it

So the broader stretch was about 3h 45m 41s with 149 actual compactions total.
If counting both compacted + context_compacted log records, that is 298 compact-related entries.

Other evidence from the same thread:

Earlier app-side error on 2026-03-08: Failed to apply patches ... [Immer] minified error nr: 18
The thread had become extremely large locally by the time this happened: ~109k rollout events and ~2.71B tokens in local thread accounting
Around 17:47Z there was also a burst of repeated task_complete -> task_started cycles before the next real user message

This did not feel like a single slow task. It felt like the app got trapped in repeated compaction and reread behavior on a very large thread.

InfiniteLife · 1 month ago

Still happens - Windows here