Compaction state is not synchronized between Codex App and CLI, and /compact cannot recover a resumed long thread

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

• #29041
• #29142
• #28920

Powered by Codex Action

检测到潜在的重复。请审核并关闭问题，如果是重复的话。 执行远程紧凑任务时出现错误：Codex 在模型上下文窗口中空间不足。重新尝试前，先开一个新话题或清除之前的历史。 #29041 macOS CLI/应用：gpt-5.5 报告 950k 上下文，但大约 260k 输入失败 #29142 * Windows 应用：Codex 报告完成工作后“模型上下文窗口空间不足”，导致线程处于不可恢复状态 #28920 _由Codex Action提供技术支持_

I reviewed the three posts above, and I believe there are many discrepancies. The issue I described is very easy to reproduce. If you follow the steps I outlined, you will definitely be able to reproduce it, because I’ve already tested four different threads—ranging from the app to the CLI—and none of them were able to inherit the compression progress from the app, nor could compression be performed via the CLI.

This is a bad situation, as it limits the ability of more users to switch from the app to the CLI in the future.

One acceptance criterion that would make this debuggable: compaction should have its own durable state record, not only an implicit transcript rewrite.

For App <-> CLI resume, I would want to see:

• a compacted-state pointer keyed by conversation id + compact revision
• the source history range the compacted state covers
• the client that wrote it
• whether the resumed client loaded compacted state or raw JSONL/history
• a recovery path that compacts only the un-compacted tail when the full replay is already over context

That last point is the important one. Once resume has loaded too much raw history, asking the model to compact the full thread is already too late. The CLI needs a bounded "use latest compact snapshot + tail" path, or at least a clear diagnostic saying it ignored/missed an available compact revision.

---

_Generated with ax._

I have a thread in vscode codex which i have been using for MONTHS. I just keep talking to it and the conversation is giant. The current thread is 2 months old, but i have some that are older.

I have my own codex CLI app, which i also use to talk to this same thread. I have been moving between vscode and this CLI app for months to talk to this thread.

This has also worked perfectly, for months. But today I'm getting the error "Error running remote compact task: Codex ran out of room in the model's context window. Start a new thread or
clear earlier history before retrying".

That has never happened before. This bug is new.

Adding a related datapoint from #30194 before closing that issue as duplicate.

In addition to /compact failing when resumed history is already too large, there is a user-visible case where compaction appears to happen but effective context usage does not materially drop. The thread still behaves near-full on the next turn, so compaction does not provide the recovery users expect.

This makes cross-surface or resumed recovery especially brittle: the user needs compaction to produce a genuinely smaller active context, or a clear failure state plus a supported fallback such as fresh context attached to the same existing worktree.

Adding a current Linux CLI datapoint. I use Codex as long-lived steward sessions, so this is not just a small UI annoyance for me. It breaks continuity for sessions that are supposed to behave more like ongoing coworkers than one-off chats.

Setup:

• codex-cli 0.142.4
• Linux
• mostly codex exec, then TUI for a manual fork/backtrack case
• long-running sessions, some used for weeks

What happened:

1. I had a long-running parent session.
2. I opened it in TUI to handle a corner case and created a fork/branch session from it.
3. I went back to the parent session.
4. In TUI I used the backtrack flow with repeated Esc to select an earlier user turn, then Enter to roll back.
5. After that, both the parent and the fork started failing with:

Error running remote compact task: Codex ran out of room in the model's context window. Start a new thread or clear earlier history before retrying.

I expected the rollback to make the active context small enough again. In practice it looks like the visible transcript and the model-visible compact payload are not the same thing. The fork/backtrack path may still carry enough compacted or inherited history that /compact itself cannot fit.

I checked the local artifacts without posting raw transcripts:

• parent rollout JSONL: about 17.3 MB
• fork rollout JSONL: about 16.1 MB
• the fork's final turn had no paired assistant output after the failing prompt

So in this case it does not look like a huge file on disk by itself. It looks more like the resumed/forked compact request is still inheriting too much model-visible history.

This feels related to #9601 for the backtrack/rollback part and #24002 for the long-resume remote compact failure. The operational shape is the same as this issue though: once a resumed or forked thread crosses the line, the command meant to reduce context cannot run anymore.

What would help from the user side:

• after rollback/fork, recompute context from the actual prompt/model-visible history, not stale or full persisted history
• a bounded resume/fork mode that uses the latest compact snapshot plus only the tail
• a clear diagnostic when Codex is about to compact full resumed/forked history and that payload is already too large
• a supported recovery path that keeps the same worktree but starts from a fresh context with an attached compact state pack

I can share private session/thread ids or more structured diagnostics if maintainers want them.

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.

Quick update from my side in case it helps other people with long-lived sessions.

My old sessions started working again after I killed a stale Codex app-server process.

In my case the CLI had already been updated, but codex app-server --listen unix:// was still running from June 20. So the TUI looked updated, while the backend doing compaction was effectively old.

What I did:

ps -eo pid,lstart,cmd | rg 'codex app-server --listen unix://'
kill <pid1> <pid2>

Then I started Codex again and resumed the old long-running session. /compact read ... worked, the session continued, and the context dropped back to a usable state.

So if you upgraded Codex but old long sessions still fail, check for a stale app-server/backend process before giving up on the session. This may not recover every broken thread, but it did recover mine.