## Summary After upgrading Codex CLI from `0.146.0` to `0.147.0`, previously completed conversations no longer replay correctly with `codex resume`. The resumed conversation shows only the beginning of the first turn and then: ```text Conversation interrupted - tell the model what to do differently. Something went wrong? Hit `/feedback` to report the issue. ``` However, the underlying rollout JSONL is complete and contains the full turn, including subsequent assistant/tool activity and an ex

Paginated history can reconstruct completed turns as “interrupted” on resume

Open 💬 5 comments Opened Aug 8, 2026 by pivot526

Summary

After upgrading Codex CLI from 0.146.0 to 0.147.0, previously completed conversations no longer replay correctly with codex resume.

The resumed conversation shows only the beginning of the first turn and then:

Conversation interrupted - tell the model what to do differently. Something went wrong? Hit `/feedback` to report the issue.

However, the underlying rollout JSONL is complete and contains the full turn, including subsequent assistant/tool activity and an explicit task_complete.

This appears to be a bug in paginated history reconstruction rather than missing or corrupted rollout data.

Environment

Codex CLI: 0.147.0
Previously: 0.146.0
OS: Linux
Installation: native Codex install script

Reproduction

Have an existing conversation containing one or more normally completed turns.
Upgrade to 0.147.0.
Resume the conversation with:

codex resume

The TUI displays only the beginning of the conversation and then marks it as interrupted.

Evidence

The underlying rollout JSONL remains intact.

For the affected turn, the rollout contains:

task_started
...
assistant/tool activity
...
final assistant output
task_complete

There are also later completed turns in the same rollout.

I queried codex app-server directly using thread/resume with paginated history. The app-server returned the affected historical turn approximately as:

thread status: idle
history mode: paginated

turn status: interrupted
items: 4

This is inconsistent with the canonical rollout, where the same turn continues substantially further and ends with task_complete.

Using excludeTurns: false did not restore the full history; the thread was still returned in paginated mode with the same truncated/interrupted reconstruction.

Troubleshooting attempted

I tried:

downgrading to 0.146.0;
deleting and rebuilding the Codex SQLite state database;
restarting Codex and resuming the same conversation.

The problem remained.

The rollout JSONL itself remained complete.

Suspected failure mode

It appears that paginated history reconstruction is materialising only a partial fragment of a completed turn.

Because the completion boundary is not included in the reconstructed fragment, the turn is subsequently treated as interrupted even though the rollout contains a valid task_complete.

Conceptually:

complete rollout
    ↓
paginated history reconstruction
    ↓
partial historical turn
    ↓
completion boundary not observed
    ↓
turn classified as interrupted
    ↓
TUI displays “Conversation interrupted”

The incorrect interrupted status is already present in the thread/resume app-server response, so the problem does not appear to be limited to TUI rendering.

Expected behaviour

Completed historical turns should be reconstructed as completed and their full conversation history should remain available after resume.

Actual behaviour

A completed historical turn is returned as interrupted with only a small subset of its items, and later history is not displayed.

Data integrity

The underlying rollout data appears to be intact. This looks like a paginated history reconstruction/migration issue rather than conversation data loss.

View original on GitHub ↗

5 Comments

shleder · 14 days ago

I’m testing Codex Rescue 0.1.0a3 against real resume/history failures. This case is useful because your canonical rollout is complete (task_complete present) while the paginated resume projection reports it as interrupted.

Rescue reads the local rollout directly, so an independent doctor result can help separate rollout damage from app-server reconstruction damage. It does not claim to repair the paginated-history bug itself.

If you still have the affected thread, would you be willing to try:

pipx install codex-rescue==0.1.0a3
codex-rescue sessions
codex-rescue doctor --latest

If it selects the right session, sanitized salvage --fork / verify output would also be useful. Please don’t post raw rollout data, prompts, SQLite DBs, credentials, or private paths.

https://github.com/shleder/codex-rescue

321Fontsize · 4 days ago

Same issue. After I run codex resume <session_id>, I can only see my first message and the error message:

■ Conversation interrupted - tell the model what to do differently. Something went wrong? Hit /feedback to report the issue.

simla-com · 3 days ago

Confirmed on Codex Desktop for Windows 11 after a recent app update (desktop package build 26.818.8289.0). This is reproducible across two independent desktop threads and is not rollout-data loss.

Observed in the Desktop UI / thread/read:

only the initial prompt and a partial first assistant item are returned;
the turn is reported as interrupted;
pagination reports hasMore=false.

The corresponding canonical rollout JSONL files parse cleanly and contain complete work:

affected thread A: 18 user messages, 42 assistant messages, 15 completed turns;
affected thread B: 13 user messages, 67 assistant messages, 9 completed turns.

Both affected threads use history_mode=paginated; a comparable unaffected current Desktop thread uses legacy. The primary local SQLite store passes integrity checks, and its rollout paths/timestamps match the complete JSONL files.

This therefore appears to affect Desktop/App history reconstruction too, not only CLI resume. No paths, prompts, project names, thread IDs, or credentials are included here. I can provide redacted aggregate diagnostics privately if maintainers need them.

CharlesZHEN · 2 days ago

Additional Desktop + Remote SSH reproduction (2026-08-25 UTC).

Environment:

ChatGPT/Codex Desktop connected to a Remote SSH app-server
Remote Codex/app-server: 0.146.0-alpha.3.1
History mode: paginated

Observed:

Reopening the affected conversation does not hydrate the complete transcript.
The app-facing thread read returns only the initial fragment, marks the turn as interrupted, and reports hasMore=false.
The canonical rollout parses successfully and contains 60 JSONL records, including two task_complete events and later completed activity.
The thread still exists in the state database and its rollout file exists. This is not transcript deletion.

Expected:

Completed historical turns must remain completed.
Pagination should expose all persisted turns.
If the history projection disagrees with the canonical rollout, Codex should automatically rebuild it instead of returning a truncated interrupted turn.
A single hydration failure should not prevent opening or switching conversations.

Privacy note:
No thread IDs, titles, prompts, workspace names, project paths, filenames, screenshots, raw transcripts, raw logs, account details, credentials, or personal information are included.

shleder · 1 day ago

For anyone whose completed turns now render as 'interrupted': in the cases I checked, the loss is projection-side - the original turns are still present in the rollout JSONL. vetto rescue diagnose <session.jsonl> classifies the file read-only (duplicate ordinals, oversized/malformed records) so you can tell damaged source from broken reconstruction before retrying resumes.