Repository navigation
Codex Desktop loses visible automation run history after restart, while run data remains on disk #23895
Description
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_HOMEis unset in the shell, so Codex is using the default~/.codexstate directory
What I observed
After restarting Codex Desktop:
- Automation runs for the project no longer appear in the app/project view.
- It looks as though all automation runs were removed.
- The automation definitions still exist under
~/.codex/automations/<automation-id>/automation.toml. - Automation-local output/memory artifacts still exist under the individual automation folders.
- Recent automation run threads still appear in
~/.codex/session_index.jsonl. - Recent archived run transcripts still exist under
~/.codex/archived_sessions/. - SQLite state/log files still exist under
~/.codex, includinglogs_2.sqliteandstate_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.
Activity
github-actions commentedon May 21, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
rello86 commentedon Jun 8, 2026
same issue, not only all automation are no longer visible but also the conversation history is lost. This is not acceptable at all as we are paying for this service, losing a conversation is a monetary damage.
rello86 commentedon Jun 8, 2026
this is really frustrating even after logging in again i cant find recent conversation and all automatons are gone. Seems to me that you restored data from an old backup. How can we restore what was lost?
nanyoudegege commentedon Jul 9, 2026
I can reproduce what looks like the same class of bug on Windows with a recurring local cron automation: the automation run threads exist in
state_5.sqlite, but the Desktop sidebar does not attach them to the local project, so they remain invisible under that project.Environment:
OpenAI.Codex_26.623.19656.0_x640.142.5croncwds: a local drive root, e.g.D:\Observed state:
state_5.sqlitewith:thread_source = 'automation'archived = 0cwd = '\\?\D:\'Automation: ...019f4465-ef03-7dc2-a16d-1486d612a31ecreated 2026-07-09 09:02 local time019f3f3d-da9d-7a70-92de-3353ab782c92created 2026-07-08 09:00 local time019f3a18-47a2-77d3-a891-4600c5ec5e47created 2026-07-07 09:01 local time.codex-global-state.jsonhas no corresponding entries for those thread IDs under:thread-project-assignmentsthread-workspace-root-hintssidebar-project-thread-orders[D:\]Expected:
cwd = '\\?\D:\', Desktop should map it back to the local project/rootD:\and show it in that project's sidebar/history automatically.Actual:
D:\project in the Desktop sidebar..codex-global-state.jsonlike:thread-project-assignments[thread_id] = { projectKind: local, projectId: D:\, cwd: D:\, pendingCoreUpdate: false }thread-workspace-root-hints[thread_id] = D:\sidebar-project-thread-orders[D:\]then the runs appear in the project sidebar.
This may be related to the path normalization boundary between
cwd = '\\?\D:\'instate_5.sqliteand the project key/rootD:\in.codex-global-state.json. Earlier I also saw failures when synthetic restored project IDs were passed as cwd, but after normalizing those to real paths this automation-run attachment issue remains.I am not attaching private state files, but the key evidence is: automation rows exist in
state_5.sqlite; the matching project assignment/order records are missing from.codex-global-state.json.boombx403-byte commentedon Aug 18, 2026
Hi @ktaletsk, your report looks related to a local session discovery/inventory gap rather than necessarily a lost rollout. I've released Codex Rescue Alpha5, a local read-only diagnostic tool that performs filesystem-first discovery across active and archived rollouts and cross-references SQLite/index metadata without modifying any state.
If you still have the affected local Codex directory, you can inspect it via:
No raw files or databases are needed. If you choose to share output, please review and sanitize any private repository paths or names first.