Windows Desktop: memory_stage1 jobs time out, leaving global memory empty

Open 💬 1 comment Opened May 9, 2026 by mtdismygo

Bug report: Codex Desktop memory generation stays empty because memory_stage1 jobs time out on Windows

Summary

Codex Desktop memory is enabled, session rollout files exist, and the memory directory is writable, but global memory remains in the initialization/template state. Investigation shows that memory_stage1 jobs in state_5.sqlite consistently fail with:

timeout waiting for child process to exit

As a result, stage1_outputs remains empty and memory_consolidate_global completes over an empty set, leaving C:\Users\ran\.codex\memories\MEMORY.md, memory_summary.md, and raw_memories.md unchanged except for baseline template content.

Environment

  • OS: Windows
  • Codex Desktop app path:

C:\Program Files\WindowsApps\OpenAI.Codex_26.506.3741.0_x64__2p2nqsd0c76g0\app\Codex.exe

  • Codex app package/version evidence:
  • Installed package path includes OpenAI.Codex_26.506.3741.0_x64__2p2nqsd0c76g0
  • Codex.exe ProductVersion: 26.506.31421
  • Codex.exe FileVersion: 2620
  • Workspace involved:

D:\work\stellar-radiance

  • Memory directory:

C:\Users\ran\.codex\memories

Config evidence

C:\Users\ran\.codex\config.toml contains:

[features]
memories = true

[memories]
generate_memories = true
use_memories = true

Filesystem evidence

The memory directory is writable from the Codex session.

  • ACL includes user ran with FullControl.
  • ACL includes CodexSandboxUsers with Modify.
  • A write/delete probe in C:\Users\ran\.codex\memories succeeded.

Current memory files remain template-like:

C:\Users\ran\.codex\memories\MEMORY.md
C:\Users\ran\.codex\memories\memory_summary.md
C:\Users\ran\.codex\memories\raw_memories.md
C:\Users\ran\.codex\memories\rollout_summaries\

raw_memories.md contains:

# Raw Memories

No raw memories yet.

rollout_summaries\ is empty.

Session evidence exists

There are multiple rollout JSONL files under:

C:\Users\ran\.codex\sessions\
C:\Users\ran\.codex\archived_sessions\

Examples from state_5.sqlite threads table for D:\work\stellar-radiance:

threads_count = 8
stage1_outputs_count = 0

Representative thread rows include:

019e0527-5baa-7212-85b4-09fc83f4ee0c
rollout_path = C:\Users\ran\.codex\sessions\2026\05\08\rollout-2026-05-08T09-15-25-019e0527-5baa-7212-85b4-09fc83f4ee0c.jsonl
title = 早上好,小co,执行唤醒流程。

019e00c0-dba1-79d2-b478-1bd3a6fbdd5d
rollout_path = C:\Users\ran\.codex\sessions\2026\05\07\rollout-2026-05-07T12-44-59-019e00c0-dba1-79d2-b478-1bd3a6fbdd5d.jsonl
title = 小co,执行唤醒流程,阅读docs中全部内容。

SQLite evidence

Query:

select count(*) from stage1_outputs;

Result:

0

Query:

select kind, job_key, status, started_at, finished_at, retry_at, retry_remaining, last_error
from jobs
where kind like 'memory_%'
order by coalesce(finished_at, started_at, retry_at, 0) desc;

Representative results:

kind: memory_consolidate_global
job_key: global
status: done
started_at_utc: 2026-05-09T05:06:16+00:00
finished_at_utc: 2026-05-09T05:06:16+00:00
last_error: null

kind: memory_stage1
job_key: 019e0527-5baa-7212-85b4-09fc83f4ee0c
status: error
started_at_utc: 2026-05-09T05:06:01+00:00
finished_at_utc: 2026-05-09T05:06:16+00:00
retry_at_utc: 2026-05-09T06:06:16+00:00
retry_remaining: 2
last_error: timeout waiting for child process to exit

kind: memory_stage1
job_key: 019e00c0-dba1-79d2-b478-1bd3a6fbdd5d
status: error
started_at_utc: 2026-05-08T03:37:39+00:00
finished_at_utc: 2026-05-08T03:37:54+00:00
retry_remaining: 0
last_error: timeout waiting for child process to exit

kind: memory_stage1
job_key: 019df857-ca22-7353-b5fb-09ef52e3bda1
status: error
started_at_utc: 2026-05-07T07:24:03+00:00
finished_at_utc: 2026-05-07T07:24:18+00:00
retry_remaining: 0
last_error: timeout waiting for child process to exit

kind: memory_stage1
job_key: 019df1e2-ba74-7ab3-a519-cccf76db344a
status: error
started_at_utc: 2026-05-05T07:09:25+00:00
finished_at_utc: 2026-05-05T07:09:41+00:00
retry_remaining: 0
last_error: timeout waiting for child process to exit

kind: memory_stage1
job_key: 019df3c9-588c-7ae1-a936-7fb5edae409d
status: error
started_at_utc: 2026-05-05T07:09:25+00:00
finished_at_utc: 2026-05-05T07:09:40+00:00
retry_remaining: 0
last_error: timeout waiting for child process to exit

Related log evidence

logs_2.sqlite also contains timeout warnings outside the memory job path, for example:

target: codex_core::session_startup_prewarm
body: startup websocket prewarm setup failed: timeout waiting for child process to exit
file: core\src\session_startup_prewarm.rs
line: 141

and:

target: codex_models_manager::manager
body: list_models{refresh_strategy=online_if_uncached}: failed to refresh available models: timeout waiting for child process to exit
file: models-manager\src\manager.rs
line: 229

This suggests a broader child-process timeout problem on Windows, not a memory-directory permission problem.

Expected behavior

After several completed Codex sessions with memory enabled, Codex should generate non-empty stage1_outputs, then consolidate them into C:\Users\ran\.codex\memories, updating MEMORY.md, memory_summary.md, raw_memories.md, and/or rollout_summaries\.

Actual behavior

All observed memory_stage1 jobs fail with timeout waiting for child process to exit. stage1_outputs stays empty, and global memory remains the initialization template:

No raw memories yet.

Impact

The user has completed about a week of high-intensity development work with Codex Desktop, but global memory remains empty. Every new session starts from the template memory state unless project-local docs are manually read.

Local diagnosis

This does not appear to be caused by:

  • Filesystem sandbox restrictions.
  • Lack of write permission to C:\Users\ran\.codex\memories.
  • Missing rollout/session evidence.
  • Disabled memory config.

It appears to be caused by the background memory_stage1 worker timing out while waiting for a child process to exit.

Requested fix

Please investigate why memory_stage1 child processes time out on Windows and whether the timeout is too short, the child process is hanging, or the worker is blocked by Windows packaged-app / sandbox / process-spawn behavior.

It would also help to expose:

  • A retry command or UI action for failed memory jobs.
  • Better diagnostics for which child process timed out.
  • A configurable or more robust timeout for memory generation.
  • A safe way to rebuild memory from existing rollout JSONL files.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗