Skip to content

Codex Desktop loses visible automation run history after restart, while run data remains on disk #23895

Open

Description

@ktaletsk

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.

Activity

  1. added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    on May 21, 2026
  2. rello86 commented on Jun 8, 2026

    @rello86

    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.

  3. rello86 commented on Jun 8, 2026

    @rello86

    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?

  4. nanyoudegege commented on Jul 9, 2026

    @nanyoudegege

    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:

    • Codex Desktop: OpenAI.Codex_26.623.19656.0_x64
    • CLI versions recorded on the affected automation threads: 0.142.5
    • OS: Windows 11
    • Automation kind: cron
    • Automation cwds: a local drive root, e.g. D:\

    Observed state:

    • Recent automation threads exist in state_5.sqlite with:
      • thread_source = 'automation'
      • archived = 0
      • cwd = '\\?\D:\'
      • titles beginning with Automation: ...
    • Example run thread IDs generated on consecutive days:
      • 019f4465-ef03-7dc2-a16d-1486d612a31e created 2026-07-09 09:02 local time
      • 019f3f3d-da9d-7a70-92de-3353ab782c92 created 2026-07-08 09:00 local time
      • 019f3a18-47a2-77d3-a891-4600c5ec5e47 created 2026-07-07 09:01 local time
    • But .codex-global-state.json has no corresponding entries for those thread IDs under:
      • thread-project-assignments
      • thread-workspace-root-hints
      • sidebar-project-thread-orders[D:\]

    Expected:

    • Since the automation run has cwd = '\\?\D:\', Desktop should map it back to the local project/root D:\ and show it in that project's sidebar/history automatically.

    Actual:

    • The automation runs are present on disk and unarchived, but they do not appear under the D:\ project in the Desktop sidebar.
    • If I manually add entries to .codex-global-state.json like:
      • thread-project-assignments[thread_id] = { projectKind: local, projectId: D:\, cwd: D:\, pendingCoreUpdate: false }
      • thread-workspace-root-hints[thread_id] = D:\
      • prepend the thread ID to sidebar-project-thread-orders[D:\]
        then the runs appear in the project sidebar.
    • However the repair can be overwritten later by Desktop's persisted frontend state, so this is only a workaround.

    This may be related to the path normalization boundary between cwd = '\\?\D:\' in state_5.sqlite and the project key/root D:\ 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.

  5. boombx403-byte commented on Aug 18, 2026

    @boombx403-byte

    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:

    pip install codex-rescue==0.1.0a5
    codex-rescue sessions --json

    No raw files or databases are needed. If you choose to share output, please review and sanitize any private repository paths or names first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appautomationsbugSomething isn't workingsessionIssues involving session (thread) management, resuming, forking, naming, archiving

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions