Codex Memories stage1 succeeds but global consolidation remains pending and no summary artifact is generated on Windows

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #21884

Powered by Codex Action

I’m seeing a very similar issue on Linux / remote CLI, so this may not be Windows-specific.

Environment:

• OS: Linux remote server
• Codex CLI: 0.142.5
• Model: gpt-5.5
• ~/.codex/config.toml has:

[features]
memories = true

Observed behavior:

• ~/.codex/memories/raw_memories.md was updated recently.
• ~/.codex/memories/rollout_summaries/ also received new summary files at the same timestamp.
• However, ~/.codex/memories/MEMORY.md and ~/.codex/memories/memory_summary.md remain stale and have not been updated since an older date.

Example state:

raw_memories.md       modified: 2026-07-06 22:09
rollout_summaries/*   modified: 2026-07-06 22:09
MEMORY.md             modified: 2026-05-05 09:42
memory_summary.md     modified: 2026-05-05 09:43

So stage/thread-level extraction appears to be working, but the global consolidation / summary artifacts are not being refreshed.

This looks closely related to the issue described here: raw memory artifacts are generated, but MEMORY.md / memory_summary.md do not get updated. Happy to provide more logs or inspect local state if there is a recommended diagnostic command.

I'm experiencing the exact same thing as you @dufu1483 and I am on Ubuntu 24.04 Linux

drwxrwxr-x  6 user user  4096 Jun 18 23:09 .
drwxrwxr-x 12 user user  4096 Jul  6 20:59 ..
drwxrwxr-x  7 user user  4096 Jun 18 23:09 .git
-rw-rw-r--  1 user user 42854 Jun 18 02:02 MEMORY.md
drwxrwxr-x  3 user user  4096 Jun 13 22:57 extensions
-rw-rw-r--  1 user user  7958 Jun 18 02:01 memory_summary.md
-rw-rw-r--  1 user user 69229 Jul  6 20:26 raw_memories.md
drwxrwxr-x  2 user user  4096 Jun 18 23:08 rollout_summaries
drwxrwxr-x  4 user user  4096 Jun 18 01:59 skills

My skills and rollout_summaries have not updated since June 18 but that's fine. However, MEMORY.md and memory_summary.md have not updated since June 18 either, even though raw_memories.md updated just fine today, and ~/.codex/memories/extensions/ad_hoc/notes/ updated just fine today with 4 new .md files too.

Still present on 0.145.0 (Windows 11), and I think I found the root cause for the missing summary artifact. Sharing analysis + reproduction + a fix outline per CONTRIBUTING.

TL;DR

Global consolidation runs a sub-agent that needs 1–2 minutes to finish. codex exec tears the process down as soon as its own turn ends, so the agent is cut off mid-work and the job is recorded as failed_agent. Giving the process enough lifetime makes the whole pipeline complete and produce both artifacts.

What I observed (0.145.0, Windows, ChatGPT auth)

Phase 1 works fine — memory_stage1 reaches done and raw_memories.md gets real content:

INFO codex_memories_write::phase1: memory stage-1 extraction complete:
     1 job(s) claimed, 1 succeeded (1 with output, 0 no output), 0 failed

But memory_consolidate_global ends as failed_agent, and no MEMORY.md / memory_summary.md is written. Logs show the consolidation agent starting and issuing shell_command calls inside the memories root — it just never reaches a final status.

Ruled out by measurement, each tested separately: missing raw material, [windows] sandbox = "elevated", an explicit memories.consolidation_model, a stale lease blocking the job, and turn lengths of 20–30 s.

The deciding experiment

Same setup, but the main turn was made long enough for the background task to finish (a single shell call sleeping ~150 s):

memory_consolidate_global -> done
memories/MEMORY.md          1544 bytes   (written by Codex)
memories/memory_summary.md   934 bytes   (starts with "v1")

A new session then answered a question that was only ever stated in the earlier, consolidated session — and answered unknown with use_memories = false. So the full chain works; it is a lifetime problem, not a defect in extraction or consolidation logic.

This also explains the two different error codes:

| last_error | meaning |
| --- | --- |
| failed_agent | sub-agent never reached a final status (loop_agent hits session_termination and returns AgentStatus::Errored) |
| failed_invalid_artifacts | agent finished, but validate_consolidation_artifacts failed — it requires MEMORY.md and memory_summary.md whose first line is exactly v1 |

I saw failed_invalid_artifacts in an interactive TUI run where phase 1 had produced nothing, i.e. the agent had no material to consolidate.

Why reproducing this is harder than it looks

Three additional conditions are silent — no log line, only a skipped_no_candidates metric — and they made this take a while to isolate:

1. push_thread_filters restricts candidates to threads.source IN ('cli','vscode') (INTERACTIVE_SESSION_SOURCES). A codex exec session writes source = 'exec' and is never eligible, so memories can only originate from interactive sessions.
2. min_rollout_idle_hours is .clamp(1, 48)-ed on load. Setting 0 in config.toml silently becomes 1, and the default is 6 — checking right after a session always finds nothing.
3. Jobs hold a one-hour lease. If the process dies mid-run, the row stays running with a future lease_until and a dead worker_id, blocking further attempts until it expires. (This may be what the pending row in the original report is about, though I could not verify that on 0.130.0.)

Fix outline

In increasing order of effort:

1. Do not treat process teardown as an agent failure. When loop_agent breaks because of session_termination, the job could be released back to pending instead of being marked failed_agent. As it stands, a normal codex exec run burns a retry attempt and puts the job into backoff for an hour, even though nothing actually went wrong.
2. Let the process wait for the pipeline when asked. An opt-in flag on codex exec (deterministic completion point) would make this workable in automation — this overlaps with the request in #29430.
3. Make the silent paths observable. skipped_no_candidates, the min_rollout_idle_hours clamp, and the source restriction are currently invisible at every log level; a single info!/warn! on each would have turned a multi-hour investigation into a two-minute one.

Not verified

I did not test on 0.130.0, so I cannot confirm that the pending state in the original report has the same cause. I also did not check macOS or Linux — the lifetime issue should be platform-independent, but the sandbox interactions may not be.

Reproduced on Windows 10 Home Single Language (build 19045) + Codex 0.146.0 stable (standalone installer via chatgpt.com/codex/install.ps1, install method = standalone, NOT AppX; previous alpha 0.146.0-alpha.3.1 had the same bug).

Concrete evidence on disk:

• ~/.codex/memories_1.sqlite (memories DB, integrity OK):
• jobs table has 1 row, kind='memory_consolidate_global', status='done', started_at=1784906285, finished_at=1784906335, input_watermark=0, last_success_watermark=0, last_error=null. Job ran ~50 s, marked itself done with zero watermarks -- no rollouts were actually consumed.
• stage1_outputs table: 0 rows.
• ~/.codex/sessions/2026/07/30/ contains 12 active rollout JSONL files (~6.0 MB) + 5 archived. state_5.sqlite.threads has 17 rows. So source data exists but is never fed into stage1.
• codex features list confirms memories stable true. No override on/off mismatch. 31 stable+enabled feature flags.
• codex doctor reports 17 ok / 1 idle / 0 warn / 0 fail -- nothing hints at the broken pipeline.
• Crucially, there is no manual trigger. Subcommands tried: codex memory, codex features memory, codex recall, codex consolidate -- none exist in 0.146.0. So even with full awareness, an end user cannot force the pipeline to run.

A new in_app_updates feature flag (stable, true) shipped in 0.146.0 -- not sure if it touches the sub-agent lifecycle, but it appears new vs 0.145.0.

Lining up with @reze83's analysis: ~50-second wall-clock for the consolidate-global job matches a sub-agent being cut off mid-flight. Our job's done status with zero watermarks is exactly the symptom of the sub-agent returning early without writing to stage1_outputs.

Environment:

• Codex 0.146.0 stable, standalone installer
• Windows 10 Home Single Language (build 19045), MSVC toolchain
• Model provider: Not OpenAI
• No AppX in play, fresh standalone install