Repository navigation
Historical sessions lose inline execution details/tool-call history after ~1 day on macOS #25486
Description
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
- Run a task/session in the Codex macOS app using Local mode.
- Wait for the task to finish.
- Expand the inline execution details.
- Observe that executed commands/actions are visible.
- Reopen the same session the next day.
- 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.
Activity
github-actions commentedon Jun 1, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
AmazingXia commentedon Aug 7, 2026
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_msgcurrently classifiesEventMsg::ExecCommandEndas 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.rshandlesExecCommandEndand reconstructs the fullThreadItem::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 persistedcustom_tool_call execresponse 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, andthread/turns/listthemselves complete successfully.Proposed minimal fix
Persist command completion events only when both conditions hold:
LegacyExecCommandSourceisAgentPaginated history continues to use
ItemCompleted(TurnItem), avoiding duplicate persistence.UserShell,UnifiedExecStartup, andUnifiedExecInteractionremain 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-rolloutpasses all 116 tests, followed byjust fix -p codex-rolloutandjust 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 commentedon Aug 7, 2026
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?