›_ Codex Issues
Codex Issues / #25486

Historical sessions lose inline execution details/tool-call history after ~1 day on macOS

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

What version of Codex are you using?

Latest version available as of June 2026.

What model were you using?

This does not appear to be model-specific.

What platform is your computer?

  • macOS Tahoe (latest)
  • MacBook Air M5

What issue are you seeing?

Immediately after a Codex session finishes, I can expand the inline execution/thread sections and inspect the commands/actions that Codex executed during the task.

However, after reopening the same session later (usually around a day later), those expandable execution details are completely gone.

The main conversation/messages are still present and intact. Only the inline execution history/tool-call/command sections disappear.

This seems specific to historical session restoration rather than the session itself being deleted.

Steps to reproduce

  1. Run a task/session in the Codex macOS app using Local mode.
  2. Wait for the task to finish.
  3. Expand the inline execution details.
  4. Observe that executed commands/actions are visible.
  5. Reopen the same session the next day.
  6. Observe that the expandable execution sections are no longer present at all.

Expected behavior

Historical sessions should preserve the full inline execution history, including executed commands/tool calls, even after reopening the app later.

Additional information

  • Running in Local mode.
  • Session data still exists locally.
  • Files/changes and normal chat history are still available.
  • Only the inline execution detail UI/history disappears.
  • The expand arrows/inline thread controls themselves disappear entirely.

Potentially related to other session persistence/indexing issues reported in the macOS app, but this specifically affects execution trace visibility in older sessions.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 2 months ago

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

  • #24390

Powered by Codex Action

AmazingXia · 21 days ago

I traced this to the legacy rollout persistence policy rather than the Desktop UI or thread loading APIs.

Root cause

codex-rs/rollout/src/policy.rs::should_persist_event_msg currently classifies EventMsg::ExecCommandEnd as transient and never persists it. This affects legacy-history threads used by the affected Desktop sessions.

The history reconstruction path is already implemented: codex-rs/app-server-protocol/src/protocol/thread_history.rs handles ExecCommandEnd and reconstructs the full ThreadItem::CommandExecution (command, cwd, stdout/stderr, aggregated output, exit code, duration, and status). On resume, however, that event is absent from the rollout, so there is nothing to reconstruct. The persisted custom_tool_call exec response item is not sufficient because the legacy response-item handler does not project the internal command execution from it.

I also verified locally that affected rollouts still contain reasoning and the exec custom tool call, but not exec_command_end; thread/read, thread/resume, and thread/turns/list themselves complete successfully.

Proposed minimal fix

Persist command completion events only when both conditions hold:

  • history mode is Legacy
  • ExecCommandSource is Agent

Paginated history continues to use ItemCompleted(TurnItem), avoiding duplicate persistence. UserShell, UnifiedExecStartup, and UnifiedExecInteraction remain excluded, preserving the existing contract that user shell commands are not returned in restored history.

I have a focused patch and regression test prepared. The test covers Agent/Legacy persistence, Agent/Paginated exclusion, and exclusion of all three non-Agent sources. just test -p codex-rollout passes all 116 tests, followed by just fix -p codex-rollout and just fmt.

Prepared patch

GitHub currently rejects both GraphQL and REST pull-request creation for this account on openai/codex, so the branch is ready to submit as soon as a maintainer enables the invitation-only contribution path.

Per the invitation-only contribution policy, could a maintainer confirm this approach and invite me to submit the PR?

AmazingXia · 21 days ago

I traced this to the legacy rollout persistence policy rather than the Desktop UI or thread loading APIs.\n\n### Root cause\n\n currently classifies as transient and never persists it. This affects legacy-history threads used by the affected Desktop sessions.\n\nThe history reconstruction path is already implemented: handles and reconstructs the full (command, cwd, stdout/stderr, aggregated output, exit code, duration, and status). On resume, however, that event is absent from the rollout, so there is nothing to reconstruct. The persisted response item is not sufficient because the legacy response-item handler does not project the internal command execution from it.\n\nI also verified locally that affected rollouts still contain reasoning and the exec custom tool call, but not ; , , and themselves complete successfully.\n\n### Proposed minimal fix\n\nPersist command completion events only when both conditions hold:\n\n- history mode is \n- is \n\nPaginated history continues to use , avoiding duplicate persistence. , , and remain excluded, preserving the existing contract that user shell commands are not returned in restored history.\n\nI have a focused patch and regression test prepared. The test covers Agent/Legacy persistence, Agent/Paginated exclusion, and exclusion of all three non-Agent sources. passes all 116 tests, followed by and .\n\nPer the invitation-only contribution policy, could a maintainer confirm this approach and invite me to submit the PR?