Automation-specific memory.md appears reset after Codex Desktop update

[isunja]

What version of the Codex App are you using (From “About Codex” dialog)?

26.506.21252 (2575)

What subscription do you have?

Pro

What platform is your computer?

Darwin 24.6.0 arm64 arm

What issue are you seeing?

After updating Codex Desktop, an automation-specific memory file appears to have been recreated/reset:

$CODEX_HOME/automations/php-8-4-feature-style-upgrade/memory.md

The file now only contains entries from today, even though a previous automation run had written and verified this same memory file.

Global Codex memory still preserved references to the older run. In particular, ~/.codex/memories/MEMORY.md and a rollout summary still reference the May 6 run and state that the automation memory file was written and verified.

I noticed this because running the automation did not seem to use prior global memory/context. I had to repeat instructions that I expected were already remembered from previous automation runs. After checking the files, I found that the automation-local memory.md only contained today’s entries, while the older context still existed in global memory/rollout summaries.

So this looks like automation-local memory was reset or overwritten, while global memory/rollout summaries survived. It also seems like automation runs may rely mainly on automation-local memory and may not reliably fall back to relevant global memory.

What steps can reproduce the bug?

1. Create or run a Codex automation that writes to:
   $CODEX_HOME/automations/<automation_id>/memory.md

2. Confirm the file contains prior run history.

3. Update Codex Desktop.

4. Run or inspect the same automation again.

5. Observe that the automation-local memory.md contains only new/current entries, while global memory still references older runs.

6. Run the automation and observe that prior instructions from older runs may not be applied unless repeated manually.

What is the expected behavior?

Codex should preserve automation-specific memory across app updates.

If the memory storage path changes, Codex should migrate or merge the old file instead of silently replacing it. If a reset is intentional, the app should leave an explicit migration/reset note.

Automation runs should also either reliably use relevant global memory as fallback, or make it clear that only automation-local memory is used.

Additional information

Evidence from local files:

• Current automation memory file only contains today’s entries:
  $CODEX_HOME/automations/php-8-4-feature-style-upgrade/memory.md

• Global memory still references the older May 6 run:
  $CODEX_HOME/memories/MEMORY.md

• The older rollout summary says the automation memory file was written and verified:
  $CODEX_HOME/memories/rollout_summaries/2026-05-06T20-06-21-0auK-php84_salesforce_array_any_refactor_and_worktree_branch_fix.md

This is risky for recurring automations because the automation-local memory appears to be the main context source during automation runs. If that file is reset and the automation does not reliably consult global memory, Codex can repeat old work or miss previously stated user preferences.

[m13v]

this is the classic post-update path-versioning miss. when an electron app bumps and the automation runner gets a new content-addressed slot under $CODEX_HOME/automations//, the old memory.md is technically still on disk but the new run resolves to a fresh slot, so it looks reset when really it's orphaned. the global MEMORY.md surviving is the tell, that path didn't get versioned. the fix isn't a migration script, it's making the automation_id stable across app versions and treating memory.md as an append-only log keyed off content hash, not install dir. otherwise every minor bump silently splits the memory tree.