/compact returns instantly and loses prior task context in 0.143.0 and 0.144.0

What version of Codex CLI is running?

codex-cli 0.144.0

What subscription do you have?

Plus

Which model were you using?

gpt-5.5

What platform is your computer?

Linux 7.1.3-100.fc43.x86_64 x86_64 unknown Fedora 43.0.0 [64-bit]

What terminal emulator and version are you using (if applicable)?

VTE terminal, version 8203 TERM=xterm-256color COLORTERM=truecolor No tmux or zellij

Codex doctor report

codex doctor --json reports overallStatus: ok

Key details:
- codexVersion: 0.144.0
- install method: npm
- platform: linux-x86_64
- auth mode: chatgpt
- model: gpt-5.5
- filesystem sandbox: unrestricted
- network sandbox: enabled
- approval policy: Never
- terminal: VTE
- terminal version: 8203
- OS: Fedora 43.0.0 [64-bit]
- no MCP servers configured
- state DB integrity: ok
- rollout DB/thread inventory parity: ok

What issue are you seeing?

/compact appears to lose essential prior conversation context in newer Codex CLI versions.

The behavior differs by version:

| Codex CLI version | /compact timing | Result after compaction |
| --- | --- | --- |
| 0.142.5 | Takes noticeable time | Prior task context is preserved |
| 0.143.0 | Completes almost instantly | Prior task context is lost |
| 0.144.0 | Completes almost instantly | Prior task context is lost |

This looks like a regression introduced after 0.142.5.

In 0.142.5, running /compact takes some time, which appears consistent with Codex actually summarizing or preserving the conversation state. After compaction, the assistant can still co
ntinue the task.

In 0.143.0 and 0.144.0, /compact completes almost immediately. After that, the assistant no longer knows what the user had asked, what task it was working on, or the relevant conversati
on history immediately before compaction. Instead of continuing the active task, the assistant responds as if the previous request is unavailable or unknown.

In my affected 0.144.0 session, after compaction I asked what I had previously asked. The assistant said it could not see the earlier request and only had environment/context information.
I then provided evidence from the interrupted/compacted state showing that the previous task involved searching/reporting Codex behavior, but the assistant still could only infer the general topic and could not recover the actual prior user request or work state.

This makes /compact unreliable for long-running Codex sessions, because compaction should preserve enough task state for the model to continue correctly. Instead, in 0.143.0 and 0.144.0
it appears to effectively reset the useful conversation context.

What steps can reproduce the bug?

1. Install or run Codex CLI 0.143.0 or 0.144.0.
2. Start a Codex CLI conversation.
3. Give the assistant a concrete task that requires context, for example asking it to investigate something or prepare a report.
4. Let the conversation continue for enough turns that compaction is useful, or manually run /compact.
5. Observe that /compact completes almost instantly.
6. Ask the assistant what the previous user request was, or ask it to continue the task.
7. Observe that the assistant does not know the prior request, the active task, or what it was doing before compaction.
8. Repeat the same flow on Codex CLI 0.142.5.
9. Observe that /compact takes noticeably longer on 0.142.5, but after it finishes the assistant preserves the prior task context correctly.

Thread id from one affected 0.144.0 session:
019f47d8-6857-7651-9b75-6397ea800446

Relevant observed behavior:

• On 0.143.0 and 0.144.0, /compact applies almost instantly.
• After compaction, the assistant said it could only see the environment context and not the prior request.
• When given a fragment showing "Searching the web" and the GitHub Codex issues URL, it could only infer the general topic.
• It could not recover the actual user request or the complete task state.
• On 0.142.5, /compact takes longer but preserves the prior context.

What is the expected behavior?

/compact should preserve enough information to continue the active task accurately, as it did in Codex CLI 0.142.5.

If compaction requires time to summarize or transfer conversation state, it should wait for that step to complete before switching to the compacted context. It should not return instantly
if the resulting compacted context does not include the prior task state.

At minimum, the compacted context should include:

• the user's latest actionable request before compaction,
• the assistant's active task or plan,
• important intermediate findings,
• any relevant URLs, files, commands, or tool results,
• and the current state of unfinished work.

The assistant should not lose the main question or respond as if the prior task is unknown immediately after compaction.

Additional information

This appears to be a regression between 0.142.5 and 0.143.0.

The timing difference may be relevant: 0.142.5 behaves as if it is doing a real summarization/compaction step, while 0.143.0 and 0.144.0 behave as if compaction is being applied without c
arrying over the previous conversation state.

This looks like a context compaction/state summarization issue rather than a terminal, install, auth, or network issue. codex doctor --json reports overallStatus ok on 0.144.0.

The issue is that after compaction, the model appears to lose the core conversation state that /compact is expected to preserve.