codex - 💡(How to fix) Fix Codex Desktop loses visible automation run history after restart, while run data remains on disk

Description

Codex Desktop appears to lose or fail to rehydrate automation run history after the app is restarted. After restart, the project's automation runs look like they have disappeared from the app UI, which makes it seem as if the automation history was deleted.

Local inspection shows the data is still present under ~/.codex, so this looks like a UI/state rehydration bug rather than actual data loss.

Related but distinct from #19747: that issue reports the Automations sidebar entry disappearing. In this case, the automation definitions and previous run/session artifacts still exist on disk, but the visible run list for the project is gone after restart.

Environment

• App: Codex Desktop
• Platform: macOS
• macOS version: 26.5, build 25F71
• Codex version file reports latest version: 0.130.0
• CODEX_HOME is unset in the shell, so Codex is using the default ~/.codex state directory

What I observed

After restarting Codex Desktop:

1. Automation runs for the project no longer appear in the app/project view.
2. It looks as though all automation runs were removed.
3. The automation definitions still exist under ~/.codex/automations/<automation-id>/automation.toml.
4. Automation-local output/memory artifacts still exist under the individual automation folders.
5. Recent automation run threads still appear in ~/.codex/session_index.jsonl.
6. Recent archived run transcripts still exist under ~/.codex/archived_sessions/.
7. SQLite state/log files still exist under ~/.codex, including logs_2.sqlite and state_5.sqlite.

For example, local inspection found six automation definition files at:

~/.codex/automations/*/automation.toml

and recent automation run thread names in:

~/.codex/session_index.jsonl

Expected behavior

After restarting Codex Desktop, the Automations/project UI should rehydrate and show existing automation runs from local state, or clearly indicate where historical runs live.

Actual behavior

After restart, the UI gives the impression that automation runs were removed from the project, even though the underlying definitions and run/session artifacts are still present under ~/.codex.

Why this matters

This makes automation history feel unreliable and makes it hard to distinguish real data loss from a UI indexing or state-loading issue. For scheduled automations, the run history is the main audit trail for whether work executed, failed, or produced artifacts.

Suggested investigation points

• Whether the project-scoped automation run list is rebuilt from session_index.jsonl, archived rollout/session files, SQLite state, or another cache.
• Whether restart clears an in-memory/project mapping from automation IDs to run threads.
• Whether runs created by cron/worktree automations are indexed differently from manually opened threads.
• Whether the UI filters runs by current project path and fails to match paths after restart, especially when the project path includes spaces or an iCloud/Obsidian directory path.