›_ Codex Issues
Codex Issues / #20696

Interrupted resume can render internal rollout_summary/raw_memory JSON as assistant output

Resolved 💬 3 comments Opened May 1, 2026 by mgwals Closed May 27, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.128.0

What subscription do you have?

Plus account.

Which model were you using?

gpt-5.5

What platform is your computer?

Linux ARM64, Ubuntu.

What terminal emulator and version are you using?

VS Code Remote SSH integrated terminal.

What issue are you seeing?

After an interrupted turn and resume, Codex persisted/rendered an internal memory JSON payload as the assistant's visible answer.

Sanitized event sequence from the session JSONL:

  1. 2026-05-01T22:09:13.652Z task_started
  2. user asked for a formatting change
  3. assistant began responding
  4. 2026-05-01T22:09:31.296Z turn_aborted
  5. 2026-05-01T22:09:38.527Z new task_started
  6. user asked Codex to continue
  7. 2026-05-01T22:10:23.126Z event_msg.type=agent_message
  8. same timestamp: persisted response_item.type=message, role=assistant, phase=final_answer, length about 28k chars, starting with a serialized JSON object:
{"rollout_summary":"[redacted internal memory payload] ...

The raw text was a serialized JSON object containing memory/stage output fields such as rollout_summary, rather than a normal assistant answer.

Around the same time, codex-tui.log recorded repeated messages of:

codex_core::util: OutputTextDelta without active item

I am not attaching raw session or log files because they contain user/session content, but the sequence above is from a sanitized local capture.

Why this seems distinct from plain stream disconnects

The corrupted-resume sequence produced a persisted assistant ResponseItem::Message with phase=final_answer. So the observable failure appears to be more than a transient display/drop issue: session state accepted an internal memory JSON payload as assistant-visible final output.

Related issues I found

  • #15720 covers OutputTextDelta without active item / dropped TUI responses.
  • #5778 covers conversation corruption after repeated interruptions.
  • #19745 covers missing lifecycle diagnostics for partial/closed streams.

I did not find an existing issue for the exact symptom "after interrupted resume, internal memory rollout_summary / raw_memory JSON is rendered as assistant output".

Expected behavior

After an interrupted turn and resume, Codex should either continue normally or fail the turn cleanly. Internal memory/stage outputs should not be persisted or rendered as the assistant's visible final answer, and orphan stream deltas should not corrupt the next turn.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 3 months ago

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

  • #20639

Powered by Codex Action

mgwals · 3 months ago

I prepared a candidate fix, but this repository currently only allows pull requests from collaborators.

Branch:
https://github.com/mgwals/codex/tree/fix-20696-aborted-resume-internal-output

Commit:
https://github.com/mgwals/codex/commit/dae31da33543ad5a8ac4d7c69d09428543cfc4e9

Summary:

  • rejects internal memory-stage JSON before it can be recorded as user-facing assistant output
  • withholds suspicious streamed prefixes until they are disambiguated or rejected
  • covers escaped JSON keys and explicit user-requested output-schema cases with tests
DongwonTTuna · 2 months ago

I am seeing this again on a newer build, so this may still be reproducible/regressed.

Environment:

  • Codex CLI: codex-cli 0.135.0-alpha.1
  • Codex latest version metadata: 0.135.0
  • Platform: macOS 26.5, Darwin arm64
  • Model: gpt-5.5
  • Memory features enabled: features.memories = true, features.chronicle = true, memories.generate_memories = true, memories.use_memories = true

Observed behavior:

After normal chat usage in Codex Desktop, internal memory JSON was emitted as the visible assistant answer. The payload started with fields like:

{"rollout_summary":"...", "rollout_slug":"...", "raw_memory":"..."}

This was not only a UI rendering artifact. It was persisted in the local session JSONL as assistant-visible output:

  • event_msg.type=agent_message contained the serialized JSON payload.
  • The immediately following response_item.type=message, role=assistant, phase=final_answer contained the same serialized JSON as output_text.

Sanitized local evidence:

~/.codex/sessions/2026/05/31/rollout-2026-05-31T14-06-08-019e7c6c-d76c-7792-ab19-ce87c374bcad.jsonl
  lines 509-510:
  event_msg.agent_message -> {"rollout_summary": ...}
  response_item.message(role=assistant).content[0].text -> same {"rollout_summary": ...}

It reproduced again in a later thread while I was trying to report the bug:

~/.codex/sessions/2026/05/31/rollout-2026-05-31T14-38-49-019e7c8a-c3c4-7c13-a9b5-56ac6749a6c0.jsonl
  lines 106-107:
  event_msg.agent_message -> {"rollout_summary": ..., "raw_memory": ...}
  response_item.message(role=assistant).content[0].text -> same internal memory JSON

Expected behavior:

Internal memory/rollout summaries should never be accepted as assistant-visible final output. If memory generation or resume/turn finalization fails, the turn should fail cleanly rather than persisting rollout_summary / raw_memory as the user-facing assistant message.