›_ Codex Issues
Codex Issues / #29430

CLI (headless/exec): synchronously generate memories for a specific session

Open 💬 3 comments Opened Jun 22, 2026 by mstrap
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What variant of Codex are you using?

CLI / headless (codex exec)

What feature would you like to see?

A headless/non-interactive way to generate memories for a specific saved session and return only after the memory has been written locally.

Examples:

  • codex memory generate <SESSION_ID>
  • codex memory generate --last
  • codex exec resume <SESSION_ID> --generate-memories --wait

This is not a request for arbitrary memory writes. It is a request for a CLI/headless surface over the existing memory-generation pipeline,
targeted at one known session.

### What problem is this solving?

Today I can make sessions memory-eligible, but in headless/exec workflows I cannot tell Codex: "generate memories from this exact session now,
and do not return until they are written."

For automation, background or deferred generation is not sufficient. I need a deterministic completion point where the session has been processed
and the memory files are already on disk. For example, after a headless run I may want to archive or copy the full Codex state/config area and know
that the generated memories are included.

### What would make this usable?

At minimum:

  • accept a session ID, plus --last
  • work in headless / codex exec workflows
  • execute extraction immediately, not just enqueue it
  • return only after memory files are written locally
  • exit non-zero on failure
  • report generated or skipped
  • include skip reasons such as session still active, memories disabled, external context excluded, rate limit, or already processed

Additional information

_No response_

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 2 months ago

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

  • #29318

Powered by Codex Action

mstrap · 2 months ago

I think this is related to #29318, but not a duplicate.

#29318 is asking for a broader centralized memory consolidation flow, including collecting session data from many temporary/headless machines and consolidating/distributing memory centrally.

This issue is narrower: a CLI/headless way to target one specific saved session (or --last) and block until that session's memories have been written locally.

So the key requirement here is session-scoped synchronous local completion semantics, not a centralized memory service.

safal207 · 2 months ago

This looks like a useful primitive not only for headless automation, but also for reliable cross-session memory workflows.

One possible addition would be a structured, session-scoped MemoryGenerationReceipt instead of relying only on human-readable stdout:

  • session_id
  • input watermark / processed source boundary
  • outcome: generated | skipped | failed
  • stable reason_code
  • generated artifact paths
  • optional artifact hashes
  • completion timestamp

This would provide:

  1. A deterministic completion boundary for --wait
  2. Idempotent handling of repeated requests for the same session
  3. Auditable provenance between a saved session and generated memories
  4. A clean primitive for the centralized consolidation flow discussed in #29318

Suggested acceptance cases:

  • successful generation
  • already processed
  • session still active
  • memories disabled
  • no eligible external context
  • consolidation failure
  • repeated invocation produces a stable result

I would be happy to help refine the data model and test matrix, and contribute an implementation if the maintainers invite a PR.