Add a post-compaction hook for deterministic memory reinjection

Resolved 💬 3 comments Opened Apr 23, 2026 by permaevidence Closed Apr 23, 2026

What variant of Codex are you using?

CLI / app-server with hooks

What feature would you like to see?

A dedicated hook that fires after Codex compacts context for a thread.

Something like PostCompact, ContextCompacted, or another official post-compaction hook event would solve this.

Why this matters

Right now Codex does not expose a post-compaction hook, so external memory systems have to use brittle workarounds.

In our case, we maintain long-term memory with hooks and want to reinject that memory exactly once on the next turn after Codex auto-compacts. Claude Code already has a hook for this class of workflow, but Codex currently does not.

Because the hook is missing, the current workaround is:

  • scan the rollout JSONL logs under ~/.codex/sessions/
  • detect the exact structural event type == "event_msg" with payload.type == "context_compacted"
  • set a one-shot pending flag
  • reinject memory on the next UserPromptSubmit

That works, but it is not a good contract to build against:

  • it depends on rollout log file naming and JSON shape staying stable
  • it forces plugins to parse internal logs instead of using an official lifecycle event
  • it is easy to get edge cases wrong around partial trailing writes, offsets, and thread/session identifiers
  • reinjection becomes "best effort on the next submit" instead of a deterministic post-compaction lifecycle event

What would help

An official hook that runs after compaction with enough metadata to act safely, for example:

  • thread_id
  • session_id
  • turn_id
  • whether compaction was automatic or manual
  • timestamp

Even a minimal official event would be much better than asking plugin authors to tail and parse rollout logs.

Ideal outcome

With a real post-compaction hook, external memory / persistence plugins could stop doing log-based detection entirely and use the supported hook path instead.

This would make custom memory reinjection much more reliable and would remove a whole class of brittle workaround logic.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗