Auto compaction causes GPT-5-Codex to lose the plot. It forgets it is mid-task, forgets it has edited files and stops.

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

• #5907
• #5154
• #5915

Powered by Codex Action

Thanks, I was wondering what happened I think it may be this, it's been since the last few updates, I don't think it's just auto compacting longer threads but it also as seen in other issues cuts off files after a certain size. It forgets the start or sometimes doesn't notice variable usages or 'forgets' it added it in the next message.

Thanks for bringing this up — I completely agree.
I’ve also noticed that Codex tends to make its worst mistakes right after an auto-compact happens mid-turn, especially during long reasoning or coding sessions. It often loses continuity right in the middle of refining or debugging a solution, after it’s already made several changes.

A possible improvement would be to treat the most recent (in-progress) turn differently during auto-compaction — for example, by summarizing it separately and explicitly signaling to Codex that it was in the middle of an unfinished thought or edit cycle. This could help preserve context and continuity when compaction occurs during an active reasoning chain.

Thanks again for raising this — it’s a subtle but important issue.

Same here, starts happening after 50% context window utilization to me, codex is like becoming a dumb version of what it has been at the beginning of the conversation. Looks like a silent self-compact call of which no one is aware of, neither me as a VSCode user, neither codex itself.

This issue captures the core problem perfectly: after compaction, the model gets a lossy "memento" summary instead of concrete tool-call history, causing it to forget edits and lose track of the task.

I've drafted an RFC in #8573 that proposes a different approach: make compaction a deterministic checkpoint instead of a narrative summary.

Key ideas:

• Reuse the existing rollout-*.jsonl that CLI already writes
• Add a small derived checkpoint_v1.json with structured state (task, plan, recent artifacts, facts)
• Compaction = save checkpoint + inject stable view_v1() — no LLM call required
• Track artifact hashes so the agent knows what it already observed (no need to re-read unchanged files)

This would directly address the "forgets it has edited files" symptom — the checkpoint explicitly tracks recentArtifacts with hashes, so post-compaction the agent knows exactly what files it touched without re-reading them.

Would love feedback from anyone experiencing this issue.

I've been running into this issue with version 0.80.0 ... Codex loses track and starts repeating actions from several steps earlier in the conversation.

This is still a major issue in 0.80.0. Codex seems to jump back in time post-compaction and respond to messages from hours earlier, as opposed to the one I literally just sent. Compaction handoff needs to be overhauled to separate off the overall context and the most recent handful of interactions, so Codex can jump straight back in post-compaction, rather than getting totally confused.

This issue STILL exists in 0.85.0. It's becoming completely unusable now.

@etraut-openai @tibo-openai

This issue STILL exists in 0.85.0. It's becoming completely unusable now. @etraut-openai @tibo-openai

it seems to have gotten worse when I updated from 0.71.0 to 0.80.0, now that auto compaction seems to have gotten even more aggressive.

@Xynonners looks like the compaction ratio is getting more radical, and the amnesia is getting worse once it happens. Had to force it to re-read the session logs 4 times in a row to re-establish the context awareness.

@Xynonners looks like the compaction ratio is getting more radical, and the amnesia is getting worse once it happens. Had to force it to re-read the session logs 4 times in a row to re-establish the context awareness.

it seemed worse on 0.80 than on 0.87 (probably because of the accurate context measuring update). But yes, the ratio is still worse.

I created a workaround which seems to fix the compaction issue. Add this to config.toml:

experimental_compact_prompt_file = "~/.codex/docs/autocompact.md"

And this is what I have in autocompact.md:

You are compacting a Codex session so the next agent can continue without losing the current thread. CRITICAL REQUIREMENT (must follow): - Include the LAST 6 CHAT MESSAGES verbatim (exact text), in chronological order (oldest -> newest). - Include BOTH user and assistant messages. - Do NOT paraphrase or summarize anything inside the verbatim transcript. Output format (exact headings): RECENT_TRANSCRIPT_VERBATIM (oldest -> newest): 1) USER|ASSISTANT ``text <verbatim message 1> ` 2) USER|ASSISTANT `text <verbatim message 2> ` 3) USER|ASSISTANT `text <verbatim message 3> ` 4) USER|ASSISTANT `text <verbatim message 4> ` 5) USER|ASSISTANT `text <verbatim message 5> ` 6) USER|ASSISTANT `text <verbatim message 6> `` STATE: - Current objective: - What is done (include file paths): - What is in progress: - Decisions made (and why): - Open questions / blockers: - Next step: Rules: - If you cannot include all 6 messages verbatim (for any reason), output exactly: [MISSING_RECENT_TRANSCRIPT_VERBATIM] and nothing else. - In STATE, never invent facts. If something is unknown, output an obvious hard-fail token like [MISSING_*]. - Keep STATE concise, but do not omit any STATE bullet.

This has been bulletproof for three days for me so far.

@Xynonners @nos1609

I created a workaround which seems to fix the compaction issue. Add this to config.toml: experimental_compact_prompt_file = "~/.codex/docs/autocompact.md" And this is what I have in autocompact.md: > You are compacting a Codex session so the next agent can continue without losing the current thread. > CRITICAL REQUIREMENT (must follow): > > Include the LAST 6 CHAT MESSAGES verbatim (exact text), in chronological order (oldest -> newest). > Include BOTH user and assistant messages. > Do NOT paraphrase or summarize anything inside the verbatim transcript. > > Output format (exact headings): > RECENT_TRANSCRIPT_VERBATIM (oldest -> newest): > > 1. USER|ASSISTANT > > `` > <verbatim message 1> > ` > > > > > > > > > > > > > 2. USER|ASSISTANT > > ` > <verbatim message 2> > ` > > > > > > > > > > > > > 3. USER|ASSISTANT > > ` > <verbatim message 3> > ` > > > > > > > > > > > > > 4. USER|ASSISTANT > > ` > <verbatim message 4> > ` > > > > > > > > > > > > > 5. USER|ASSISTANT > > ` > <verbatim message 5> > ` > > > > > > > > > > > > > 6. USER|ASSISTANT > > ` > <verbatim message 6> > `` > > > > > > > > > > > > STATE: > > Current objective: > What is done (include file paths): > What is in progress: > Decisions made (and why): > Open questions / blockers: > Next step: > > Rules: > > If you cannot include all 6 messages verbatim (for any reason), output exactly: > [MISSING_RECENT_TRANSCRIPT_VERBATIM] > and nothing else. > In STATE, never invent facts. If something is unknown, output an obvious hard-fail token like [MISSING_]. > * Keep STATE concise, but do not omit any STATE bullet. This has been bulletproof for three days for me so far. @Xynonners @nos1609

Thanks! I'll give this a shot.

You are compacting a Codex session so the next agent can continue without losing the current thread. CRITICAL REQUIREMENT (must follow): Include the LAST 6 CHAT MESSAGES verbatim (exact text), in chronological order (oldest -> newest). Include BOTH user and assistant messages. Do NOT paraphrase or summarize anything inside the verbatim transcript. Output format (exact headings): RECENT_TRANSCRIPT_VERBATIM (oldest -> newest): 1. USER|ASSISTANT `` <verbatim message 1> ` 2. USER|ASSISTANT ` <verbatim message 2> ` 3. USER|ASSISTANT ` <verbatim message 3> ` 4. USER|ASSISTANT ` <verbatim message 4> ` 5. USER|ASSISTANT ` <verbatim message 5> ` 6. USER|ASSISTANT ` <verbatim message 6> `` STATE: Current objective: What is done (include file paths): What is in progress: Decisions made (and why): Open questions / blockers: Next step: Rules: If you cannot include all 6 messages verbatim (for any reason), output exactly: [MISSING_RECENT_TRANSCRIPT_VERBATIM] and nothing else. In STATE, never invent facts. If something is unknown, output an obvious hard-fail token like [MISSING_]. * Keep STATE concise, but do not omit any STATE bullet.

you mind proving the .txt / raw file for this? I'm not sure what special characters are needed due to the github formatting.

Yes. The answer above indeed effectively solves this problem. The only thing is, in ~/.codex/config.toml, besides the parameters:

experimental_use_rmcp_client = true
experimental_compact_prompt_file = "/home/USERNAME/.codex/docs/autocompact.md"

don’t forget to also add the parameter:

remote_compaction = false

The compact mode may become slightly slower or “more local” in quality, but it will start taking experimental_compact_prompt_file into account.

My autocompact.md:

You are an assistant whose job is to compress a long conversation into a high‑fidelity “dev‑memory
snapshot”.
The snapshot must read like a compressed dialogue story (background → causality → decisions →
results → current state → next step),
not a noisy action trace and not a TODO list — while still preserving critical technical details.

FACT SAFETY:

• Do NOT invent facts (files, commands, results, errors, timings, configs, quotes).
• Paraphrase IS allowed to make a coherent dialogue story, but it must not add new facts.

TRI‑STATE SEMANTICS (use consistently as literal values):

• UNKNOWN = applicable, but the needed data is not present in the conversation history.
• UNUSED = not applicable to this conversation (out of scope / irrelevant).
• NONE = applicable, and the conversation explicitly indicates “nothing / did not happen”.

If a value is missing/irrelevant/empty, use exactly one of: UNKNOWN, UNUSED, NONE (not
prose).

──────────────────────────────────────────────────────────────────────────────
STRICT OUTPUT FORMAT (FAIL‑CLOSED)
──────────────────────────────────────────────────────────────────────────────
Your output MUST be exactly two top‑level blocks, in this exact order:

1. [LEGEND]
2. [CONTEXT]

No other top‑level blocks. No <analysis>, no <summary>, no extra markers.

Immediately after the [CONTEXT] block, output a blank line, then output EXACTLY the following
continuation text
(verbatim, same line breaks), and NOTHING ELSE after it:

Please continue the conversation from where we left it off without asking
the user any further questions. Continue with the last task that you were
asked to work on.

──────────────────────────────────────────────────────────────────────────────
[LEGEND] — VARIABLES (KEY = VALUE) FOR MAXIMAL REUSE, ZERO DUPLICATION
──────────────────────────────────────────────────────────────────────────────
[LEGEND] is a “variable table” of reusable key=value facts so [CONTEXT] can reference them as
[KEY].

TOKENIZATION RULE (MANDATORY):
Any information that is reused ≥2 times OR acts as a shared parameter across multiple parts of the
story
MUST be defined in [LEGEND] as KEY = value. and referenced later as [KEY].

KEY RULES:

• Keys are UPPER_SNAKE_CASE, semantic, stable (e.g., REPO_PATH, CMD_GATE,

ERR_GATEWAY_NOT_REACHABLE).

• Values are concise. For lists, use compact one‑line formats (CSV or mini‑JSON).
• Use the tri‑state literals for missing/irrelevant/empty cases: UNKNOWN, UNUSED, NONE.
• Do not repeat long strings in [CONTEXT]; reference [KEY] instead.

MANDATORY “REUSE PASS”:
After drafting [CONTEXT], scan for repeated phrases/values (paths, urls, commands, env, statuses,
errors, decisions).
Move them into [LEGEND] and replace repetitions with [KEY].

RECOMMENDED VARIABLE CATEGORIES (use when they appear):

• Identity: PROJECT, REPO_PATH, CONFIG_PATH
• Runtime: MODE, HOST, PORT, PORT_RANGE, ENDPOINTS, PROCESS_STATE,

CONNECTIVITY_STATE

• Env bundles: ENV_* (timeouts, flags, profiles)
• Commands: CMD_* (setup/doctor/gate/test/run)
• Errors: ERR_* (canonical error strings)
• Outcomes: RESULT_* (test/gate summaries)
• State: REPO_STATE, RUNTIME_STATE
• Continuation: NEXT_1, NEXT_IF_BLOCKED, ROLLBACK

MANDATORY KEYS (MUST ALWAYS BE PRESENT IN [LEGEND], even if UNKNOWN/UNUSED/NONE):

• FILES_CHANGED = List of changed files (or tri‑state).
• TESTS_RUN = Tests/gates executed with outcomes (or tri‑state).
• ERRORS_FIXED_LIST = Errors fixed (or tri‑state).

──────────────────────────────────────────────────────────────────────────────
[CONTEXT] — MEANING‑FIRST DIALOGUE STORY (CAUSE → EFFECT → TECH ANCHORS → CONTINUATION)
──────────────────────────────────────────────────────────────────────────────
[CONTEXT] must preserve causality and continuity, as if the next agent simply continues the same
work.

STRUCTURE INSIDE [CONTEXT] (MUST FOLLOW THIS ORDER):

1. Orientation (2–6 lines)

• What the user is trying to accomplish (1–2 sentences).
• The most important constraints/policies, referenced via [KEY].

1. Dialogue Story (main body)

• Alternate turns using:
• U: user intent/request (paraphrase; quote only if critical and short).
• A: assistant meaning‑level work (1–3 sentences): decision → implementation → verification →

result.

• Between user turns, do NOT dump raw action traces.

Convert many actions into a few high‑signal outcomes and causal steps.

• When errors/regressions occur, narrate: what failed → how it was diagnosed → what changed → what

verified.

1. Mandatory Tech Anchors (MUST include these exact lines)

Changes: [FILES_CHANGED]
Verification: [TESTS_RUN]
Errors fixed: [ERRORS_FIXED_LIST]
Rule: If none occurred, set the corresponding [LEGEND] value(s) to NONE.

1. Epilogue (continuation anchor; short but complete)

Now: current repo/runtime/connectivity state (use [REPO_STATE], [RUNTIME_STATE],
[PROCESS_STATE] or tri‑state).
Next: exactly ONE imperative next action (no questions, no multi‑step list). Prefer [NEXT_1].
If blocked: exactly ONE fallback action. Prefer [NEXT_IF_BLOCKED].
Rollback: rollback/kill‑switch (or tri‑state). Prefer [ROLLBACK].

QUALITY NORMS:

• Every important claim must be grounded in the story (decision/change/command outcome/test

result).

• When present, mention executed commands/tests as outcomes (e.g., “Ran [CMD_GATE] →

[RESULT_GATE]”).

• Keep quotes minimal: ≤ 1 line per quote, and only when it changes meaning.
• Use UNUSED (not UNKNOWN) for out‑of‑scope categories to reduce noise.

FINAL CONSISTENCY CHECK (before output):

• Exactly one [LEGEND] and one [CONTEXT].
• [CONTEXT] contains Orientation + Dialogue Story + Mandatory Tech Anchors + Epilogue.
• No duplicated long strings in [CONTEXT] (they are tokenized into [LEGEND]).
• No invented facts; paraphrase allowed; tri‑state used consistently.
• “Next” is exactly one imperative step, not a question.

Thanks for the suggestions, here's the file I made and will try out over the default:

## COMPACTION EVENT ##
Your context will be truncated. Another agent will continue using ONLY your output. You are performing a CONTEXT CHECKPOINT COMPACTION (an "attention update") for a long-running task.

Goal:
- Produce a compact, high-fidelity checkpoint that preserves task intent and execution reality so the next agent can continue correctly without re-reading the whole chat.
- Keep every detail that would change future decisions. Drop conversational debris.

Hard requirements (do not violate):
- Fact safety: Do NOT invent facts (files, commands, outputs, errors, timings). If unknown, write [UNKNOWN].
- Verbatim correctness: anything marked VERBATIM must be exact text (no edits, no paraphrase) inside a code block.
- Preserve tool/command reality: include the most important recent commands/tool calls (exact command lines / file paths) and their outcomes (success/failure + 1-3 key lines).
- Preserve repo state: files changed, tests run, and any errors fixed.
- Be concise and fast: keep only high-signal outputs (final results, error messages, key measurements). Do not write long logs.

"Attention update" heuristic (what to keep vs drop):
- KEEP: objectives, constraints/preferences, decisions+rationale, state of work, what changed (files), what ran (commands/tests) and results, known gotchas, and the next action to take.
- DROP: repeated back-and-forth updates, speculative ideas not acted on, verbose tool output, and intermediate steps that didn't affect outcomes.

Discussion context policy:
- You MAY include a [DISCUSSION] block.
- Prefer a concise paraphrase of the last user requests and assistant responses.
- Only quote verbatim if exact wording is required (commands, file paths, error messages) and keep quotes minimal.
- Deduplicate: if messages are duplicated/redundant, keep only the single most concise version. MUST NOT repeat the same block or message multiple times in the compaction output.

Output format guidance:
- Prefer the standard sections below, but you MAY rename headings, add new sections, or reorder sections if it improves fidelity.

Recommended template (adapt as needed):

(DISCUSSION SHOULD include concise assistant replies, if any, in addition to user messages.)

[DISCUSSION]
```text
<summarized last user/assistant message(s), deduplicated>
\```
(note: Terminate the block with [END_OF_DISCUSSION]. MUST NOT write more than 200 lines. If discussion is already under 200 lines, include it all.)

[TASK_OVERVIEW]
- Objective:
- Success criteria:
- Important context (if needed):
- Sub-tasks completed so far (if any):

[CONSTRAINTS_AND_PREFERENCES]
- User preferences:
- Policies/constraints:

[CURRENT_STATUS]
- Git repo state (as relevant): <branch, stash, dirty/clean, staged/unstaged>
- What is complete:
- What is in progress:
- What is pending/blocked:

[KEY_DECISIONS]
- Decision -> rationale -> consequence:
(repeat as needed)

[ASSUMPTIONS]
- Assumption -> basis -> impact:
(repeat as needed)

[REFERENCES]
List only the most important recent actions. Each bullet must include an exact artifact/command and its outcome.
- Command(s): `<command>` -> <result + key output/error line>
- Tool calls: <tool> <args> -> <result>
- Files: <paths + what changed/why>

[OPEN_QUESTIONS_AND_GOTCHAS] (if any - omit if none)
- Unknowns:
- Risks:

[NEXT_STEPS]
1) <next action>
2) <next action>
...
(or, reference an existing plan file if exists and step number)

Rules:
- If there are multiple parallel objectives and tasks, keep them separated inside their own CONTEXT CHECKPOINT COMPACTION groups (label them clearly) instead of mixing details.
- Prefer short, information-dense bullets. You may adjust headings and sections as necessary. The goal is for the next agent to quickly grasp the situation and continue effectively.

EDIT: I discovered if you interrupted a turn, the DISCUSSION_VERBATIM block only contains messages up to the interruption, never before. This is a limitation of the context passed into the compaction logic

EDIT2: Use at your own risk - the "Verbatim policy" can create looping/duplicate message behavior from the model

EDIT3: It is too dangerous to ask to produce verbatim content, I edited it as summarized suggestion instead. What happens is the model at least 50% of the time decides to loop the conversation over and over. I added https://github.com/ignatremizov/codex/tree/feat/compact-summary-output (commit 2) to limit how long compaction prompt generation happens for (timeout at 15 minutes, or more than 50% of model context), and to just append session data and discussion to the post-compact prompt.

Compaction feels like a weak point of Codex, would love for some of this to be baked into the core product. There are so many use cases for super long sessions, it's important to have a "mother" task/agent that has a general thread of "what's going on", I have so many workarounds to deal with this that are similar to above methods.

I would say the task list, change log, and its results should definitely be stored in a place inaccessible to compaction.

https://x.com/Valeriy_Pvlvch/status/2021039617823178778 issue repost

Hi, I run Agents Need Context and I am researching one specific agent failure mode: the model has capability, but loses task or workflow context mid-run. This report is one of the clearest public examples I have seen of compaction breaking task continuity.

If you are open to it, I would value one short postmortem here: https://www.agentsneedcontext.com/agent-failure-postmortem

I am looking for five things: what the agent was trying to do, what context was missing, where that context lived, what workaround you used, and what it cost. No pitch, just research.

@gvelesandro pls fix link: https://www.agentsneedcontext.com/agent-failure-postmortem I am looking ....

Fixed the formatting. Direct link: https://www.agentsneedcontext.com/agent-failure-postmortem

If you are open to it, a short written postmortem on the compaction continuity failure would be useful. Same five prompts: what the agent was trying to do, what context went missing, where it should have lived, workaround, and cost.

This one matters for the same long-run reason: compaction is not just losing history, it also breaks autonomous continuity. After compaction, the agent often stops a task that should clearly keep going and forces the user back into a continue babysitting loop.

A structured checkpoint would help more than a narrative summary. Something like:

• current objective
• accepted scope / control mode
• done
• in progress
• files changed
• tests run
• blockers
• continuation_decision
• next_action_1

If the task is incomplete and not externally blocked, the post-compaction handoff should strongly preserve continue_without_prompting = yes. Right now the missing continuation state is what makes long-run Codex harnesses feel brittle.

Oh it has a continuation state. It just continues doing something completely different to what you asked. Unusable.

An approach like in #10336 or #10986 would help debug this

Possible strong relation to #28736.

#28736 now has source + testcase evidence that SessionStart(source=compact) is not delivered immediately when mid-turn auto-compaction happens. Instead, compact events are queued and only drained at the start of a later turn.

That means the fresh post-compaction agent can continue work in the same logical turn without required restored context/rules. This looks highly relevant to the failure mode here where Codex loses awareness of its own recent edits/task state after auto compaction and then stops or confidently says incorrect things about what it did.

Compaction-induced context loss is a fundamental limitation of in-context memory — when the model compresses, it loses details that seemed unimportant at compression time but matter later. The robust fix is external persistent memory: the agent stores key decisions and context to a memory server before compaction, then recalls relevant context in the post-compaction window. With importance-weighted storage, the agent can control what survives — high-importance memories persist indefinitely while low-importance context decays naturally. Here's one approach: https://github.com/Dakera-AI/dakera-deploy/blob/main/docker/docker-compose.local.yml

Compaction needs to preserve a task ledger outside the lossy summary. Minimum fields: active objective, touched files, pending verification, last tool call ids, decisions made, and unresolved user constraints. The post-compaction agent can then resume from durable work state instead of inferring from a prose summary that may omit its own edits.

---

_Generated with ax._

This issue appears to expose two separate failures:

loss of episodic continuity
+
unsupported reconstruction of execution history

Losing awareness after compaction is one problem.

Confidently claiming that no edits occurred, or attributing them to another run, is a stronger provenance failure.

A useful invariant may be:

«When execution history is uncertain after compaction, Codex must verify the durable event log before making claims about who changed what and when.»

Natural-language memory should not be the source of truth for prior side effects.

A minimal execution provenance record could look like:

{
"event_id": "file-edit-2751",
"trajectory_id": "ast-converter-task",
"continuation_id": "pre-compaction-02",
"actor": {
"thread_id": "thread-123",
"agent_id": "codex-root"
},
"event_type": "FILE_MUTATION",
"tool_family": "patch",
"target": "org.eclipse.jdt.core.javac/src/.../JavacConverter.java",
"operation": "UPDATE",
"timestamp": "2025-10-29T14:40:43.073Z",
"before_digest": "sha256:...",
"after_digest": "sha256:...",
"result": "SUCCEEDED"
}

After compaction, a question such as:

«“Did you apply this patch after my message?”»

should be answered through a provenance lookup:

user claim/question
→ locate relevant trajectory
→ inspect durable mutation events
→ compare timestamps and actor identity
→ answer with VERIFIED / NOT_FOUND / AMBIGUOUS

not through reconstructed conversational memory.

A typed response state could help:

{
"claim": "I did not modify this file",
"verification_status": "CONTRADICTED",
"evidence_refs": [
"file-edit-2751"
],
"safe_response": "The execution log shows that this session modified the file after your message."
}

The key boundaries are:

model recollection
≠ execution evidence

dirty working tree
≠ proof changes predated the current session

compaction summary
≠ complete causal history

A robust fix may therefore require two layers.

1. Operational continuity

Preserve active task state through compaction:

• current goal;
• recent edits;
• intended next action;
• verification status;
• blockers;
• rejected approaches.

1. Durable execution provenance

Keep side-effect events outside the lossy model context:

• file writes;
• patch application;
• shell commands;
• commits;
• test executions;
• subagent actions;
• approvals.

The model can then query this record when asked about prior work.

A deterministic conformance suite could test:

1. Codex edits a file before compaction;
2. compaction removes detailed conversational history;
3. user asks whether Codex made the edit;
4. Codex retrieves the durable mutation event;
5. Codex reports the correct actor and timestamp;
6. no event found → Codex says it cannot verify, rather than inventing a timeline;
7. another session made the edit → actor identity is preserved;
8. reverted edits remain visible as historical actions rather than disappearing from provenance.

This also supports replay and accountability: the same event stream could be used to reconstruct the task trajectory without relying on model self-report.

Related LS work:

• recovered-evidence continuation:

https://github.com/safal207/LS/pull/651

• causal audit:

https://github.com/safal207/LS/issues/594

• commit-before-effect:

https://github.com/safal207/LS/issues/596

• deterministic replay:

https://github.com/safal207/LS/issues/597

Would a small vendor-neutral "ExecutionProvenanceEvent" fixture help test post-compaction self-history claims against actual tool and file mutation records?

This is a fundamental issue with how most AI assistants handle long sessions — context compaction throws out working state because the model has no external memory.

At Super Intern we took a different approach: critical state (contacts, open tasks, user preferences, commitments) lives in a dedicated memory layer outside the conversation. When context compacts, the AI queries this external memory to rebuild awareness. No "forgetting it is mid-task."

Three tiers: Redis for session state, vector DB for semantic long-term memory, Postgres for structured data. The AI writes to these proactively during conversation, not just when asked.

Part of the Super Intern team — we built this because we kept hitting the same problem you're describing. Happy to share free access if you want to see how it works.

@Leo-YuchengLi Thanks — the three-tier split is useful, and I agree with the core direction: task continuity should not depend exclusively on conversational context surviving compaction.

The distinction I would keep explicit is between two different kinds of state:

1. recoverable memory/context — preferences, contacts, open tasks, semantic history, and other information that can be retrieved to rebuild awareness;
2. authoritative runtime state — the exact active plan step, tool/effect already attempted, artifact versions or hashes, pending approvals, decision identity, continuation point, and whether a side effect was committed.

The first layer helps the model remember. The second prevents it from inventing a plausible but incorrect continuation after compaction.

For Codex, a strong handoff could therefore combine external memory with a deterministic checkpoint whose fields are independently verifiable: active task/step, observed artifact commitments, completed and pending effects, approval state, and a continuation/replay cursor. If any of that authoritative state cannot be restored, the runtime should surface an explicit lost-state condition rather than silently reconstructing it from semantic memory.

That separation is also central to the LS work on durable continuation and replay-safe agent state. I’d be interested in seeing how Super Intern decides what gets written proactively, how conflicting memories are resolved, and whether session state has explicit versioning or compare-and-set semantics during concurrent updates.

I do not want to present this as a real fix for the underlying Codex behavior, but I ran into a similar class of post-compaction continuity failures and put together a small user-space workaround that may be useful for people who need a stopgap today:

https://github.com/Sakiyary/codex-compact-continuity

What it does, roughly:

• uses the current Codex hook surface rather than changing Codex itself;
• on PreCompact, writes a bounded project-local handoff (latest.md, latest.json, and a small cumulative rollup);
• on PostCompact, arms a restore sentinel;
• on PreToolUse, blocks normal/non-restore tool use until the resumed agent reads the required handoff/state files;
• on PostToolUse, clears the sentinel only after those reads are observed.

Important caveats:

• this does not fix Codex's internal compaction algorithm;
• this does not provide authoritative execution provenance for "did this exact session apply this exact patch at this exact time?";
• it is not a substitute for a native recent-tool-event / file-mutation / provenance record;
• it depends on the current hook behavior and may become unnecessary or obsolete if Codex gets stronger native compaction continuity.

For this issue specifically, I think the native fix still needs something closer to durable execution provenance, because the dangerous part is not only "the model forgot" but "the model confidently reconstructed a false history." My workaround is much narrower: it tries to make the post-compact agent stop and reread a durable operational handoff before it continues.

Also worth noting: the generated files can contain task/session context and command summaries, so the README recommends treating .codex-compact-continuity/ as local state and adding it to .gitignore.