Codex Desktop deletes heartbeat automation definition after restart when target thread is archived

Summary

Codex Desktop appears to have silently removed one heartbeat automation after restart. This was not only a sidebar display issue: the automation definition was missing from both $HOME/.codex/automations and the SQLite automations table, while archived automation run threads still existed.

This looks related to automation/session persistence issues such as #23895, but seems more severe because the automation definition itself disappeared.

Environment

• Codex Desktop: 26.519.41501
• Codex app bundle version: 3044
• Codex CLI: codex-cli 0.130.0
• Platform: Darwin 25.5.0 arm64 arm
• Automation type: heartbeat automation attached to a thread
• Automation schedule: daily evening run
• Target thread state found later: archived

I have intentionally redacted local usernames, exact local thread ids, and account-specific prompt content from this report.

What Happened

Before restarting Codex Desktop, I had two active automations:

• a Gmail automation
• a GitHub automation

After restarting Codex Desktop, only the Gmail automation was visible in the Automations sidebar.

Local inspection matched the UI state:

$HOME/.codex/automations/gmail/automation.toml

The missing GitHub automation was absent from both persistence layers:

$HOME/.codex/automations/github/automation.toml  # did not exist
$HOME/.codex/sqlite/codex-dev.db                # automations table only contained gmail

However, archived session state still contained previous GitHub automation run threads. The latest matching archived thread had metadata like:

title: Automation: GitHub
Automation ID: github
cwd: <project path containing spaces>
archived: 1

Archived automation transcript text also referenced:

Automation: GitHub
Automation ID: github
Automation memory: $CODEX_HOME/automations/github/memory.md
Last run: <timestamp>

So the automation appears to have existed and run before restart, then disappeared as a definition while its archived run threads remained.

Expected Behavior

Restarting Codex Desktop should not silently remove a heartbeat automation definition from:

• $HOME/.codex/automations/<automation-id>/automation.toml
• $HOME/.codex/sqlite/codex-dev.db, table automations

If the target thread has been archived, the automation should remain visible with a warning, keep running against that thread, or ask the user to choose a new target thread. It should not be removed without confirmation.

Actual Behavior

The GitHub heartbeat automation disappeared from:

• the Automations sidebar
• $HOME/.codex/automations
• the SQLite automations table

Archived automation run threads remained, which makes this look like an automation definition persistence, cleanup, or rehydration bug rather than an intentional deletion.

Recovery

I recreated the missing automation from Codex Desktop. After recreation, both persistence layers contained the automation again:

$HOME/.codex/automations/github/automation.toml
$HOME/.codex/automations/github/memory.md
codex-dev.db automations row: id=github, status=ACTIVE

Why This Is Not Exactly #23895

#23895 reports automation run history disappearing while definitions remain on disk.

In this case, the archived run history still existed, but the automation definition itself was missing from both the file-backed automation directory and the SQLite automations table.

Suggested Investigation Points

• Whether heartbeat automations whose target_thread_id points at an archived thread are pruned on startup.
• Whether a failed automation rehydration can delete the automation definition instead of only hiding it from the sidebar.
• Whether project-scoped automation threads under paths containing spaces are matched incorrectly after restart.
• Whether the Automations sidebar is rebuilt from codex-dev.db, $HOME/.codex/automations, session_index.jsonl, or another cache, and whether those sources can diverge.