Context compaction loses operational continuity in long Codex tasks; preserve the last 5 operational steps verbatim

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

• #29354
• #28892

Powered by Codex Action

I reviewed the suggested potential duplicates.

I agree this issue is related to #29354 and #28892, but I do not think it is an exact duplicate.

#29354 describes a repeated pre-write loop where Codex rereads the same files after compaction and never reaches implementation. #28892 focuses on steered follow-ups / mid-turn user input around compaction.

This issue is asking for a more general compaction behavior change: preserve the last 5 operational steps verbatim or structurally losslessly, so Codex can continue the active task after compaction without reconstructing it from a vague summary.

So I see this as related, but distinct.

I would like to add a related product-level suggestion based on a long-running Codex workflow where context compaction became a recurring operational risk.

The issue is not only that compaction can lose the last few operational steps. There is also a missing first-party handoff policy for when a thread has become too large or too valuable to keep compressing safely.

A useful behavior would be for Codex to distinguish between two cases:

1. Project-bound threads

If the current thread clearly belongs to a project, repository, workspace, or long-running workflow, Codex should proactively maintain a durable project handoff artifact before risky compaction or before switching to a new phase.

That handoff should include, at minimum:

• current objective;
• key decisions and user constraints;
• completed work and explicitly rejected approaches;
• files, modules, reports, or evidence paths that matter;
• current candidate or working state;
• unresolved blockers or risks;
• exact next actions;
• the files or notes a fresh thread must read before continuing.

The goal is that a new Codex thread can resume from project-local state instead of depending on a fragile compressed transcript.

1. Standalone / non-project threads

If the current thread is not attached to a durable project or workspace, and the conversation has become too large to keep compressing productively, Codex should explicitly prompt the user to archive the current thread and start a new one.

In that case, Codex should provide a copyable continuation summary before the archive/new-thread handoff, rather than silently continuing until another compaction loses nuance.

Important distinction:

Archive should not be treated as memory. A hidden or archived thread is not a reliable continuity mechanism by itself. If information must be reused later, Codex should first help persist it as a project handoff, workspace file, durable note, or explicit continuation summary.

This would complement the requested “lossless recent operational tail” from the main issue. The recent operational tail protects immediate continuity inside compaction; the handoff policy protects the user when a thread should stop being compressed and should instead transition to a fresh thread safely.

Expected user-facing behavior:

• Before or after compaction, Codex detects that the current thread is becoming risky to compress further.
• For project work, Codex updates or creates a project handoff card.
• For non-project work, Codex recommends archiving and starting a new thread, with a concise continuation summary.
• Codex does not claim it can always predict the exact moment before automatic compaction; instead, it performs proactive stage-based handoff at natural boundaries such as completing a round of work, finishing a deep analysis, changing task phase, or after a compaction event.

This would make long-running Codex work much safer for research, development, debugging, documentation, and other workflows where losing subtle decisions can invalidate hours of work.

I think this is a useful complementary direction, but I would distinguish it from the core request in this issue.

The "lossless recent operational tail" should be part of the compaction mechanism itself. It protects immediate continuity inside the same active thread: the agent should not lose the latest user instruction, recent tool/action sequence, touched files, rejected approaches, current verification target, and next step.

A project/thread handoff policy solves a different layer: what to do when the thread has become too large, too valuable, or too risky to keep compressing safely.

I would support a handoff mechanism as an escalation path, but not as a replacement for improving compaction.

The risk is that, if implemented as another agent-written scratchpad or summary, it could recreate the same problem in a different form:

• more process artifacts,
• more context consumed,
• more notes the agent may forget to read,
• more user supervision.

So I think the product behavior should be:

1. Compaction always preserves the recent operational tail losslessly or near-losslessly.
2. When a thread becomes risky to compress further, Codex can create or update a bounded first-party handoff artifact.
3. That artifact should be concise, structured, and project-aware, not an ever-growing manual note.
4. It should point to the real sources of truth: files, diffs, tests, logs, reports, artifacts, and next actions.
5. It should be used for safe transition to a new thread or phase, not as a substitute for preserving the active operational tail.

In short:

• Recent operational tail = protects continuity inside compaction.
• Handoff policy = protects continuity when the thread should stop being compressed and transition safely.

I would not want the handoff mechanism to become "another summary the agent writes and then forgets." It needs to be first-party, bounded, and tied to project/workspace state.

Thanks, Daryll. I really appreciate the careful and professional way you framed this. Your distinction makes sense to me, and it helps separate two things that I had been thinking about together but that probably should not be implemented as one large change.

Based on your feedback, I think the safest path would be to split this into three PR-sized tracks instead of treating handoff as a replacement for compaction improvement:

PR 1: Preserve the recent operational tail during compaction

This should be the core fix for this issue.

The idea would be to make compaction preserve a bounded recent operational tail as first-party structured context, ideally derived from the session/tool event log rather than from another model-written scratchpad.

That tail should preserve, losslessly or near-losslessly:

• the latest user instruction and constraints;
• the recent tool/action sequence;
• touched or relevant files;
• rejected approaches and why they were rejected;
• the current verification target;
• blockers or risks;
• the next intended step.

In other words:

Compacted context = summarized older history + durable instructions + bounded recent operational tail

This would keep the active thread coherent immediately after compaction without requiring the user to restate the work or supervise a manual note.

Non-goals for this first PR:

• not moving conversations between projects;
• not creating a manual scratchpad;
• not preserving the entire transcript verbatim;
• not using handoff as a substitute for compaction correctness.

PR 2: Add a bounded first-party project/workspace handoff artifact

This would be a separate escalation path for the case you described: when a thread has become too large, too valuable, or too risky to keep compressing safely.

I agree this should not be another ever-growing agent-written summary. It should be first-party, bounded, structured, and tied to project/workspace state.

It should point to the real sources of truth, for example:

• files and directories;
• diffs;
• tests and commands;
• logs;
• reports or generated artifacts;
• current blockers;
• exact next actions.

The goal would be safe transition to a new thread or phase, not replacing the active operational tail inside compaction.

PR 3: Project/thread attachment or transition UX

This would be the product-level follow-up related to cases like #24519: when a user starts in a general chat and later realizes the work belongs to a specific project.

This should probably come after the first two pieces, because attaching or moving a thread is much more useful if Codex already has:

1. reliable recent operational continuity after compaction; and
2. a bounded project-aware handoff artifact for safe transition.

So my current understanding is:

• Recent operational tail protects continuity inside compaction.
• Handoff artifact protects continuity when the thread should stop being compressed and transition safely.
• Project/thread attachment is the UX layer that helps attach that work to the right project without fragmenting history.

Thanks again for taking the time to discuss this so seriously. I appreciate it, and your framing makes the implementation path feel much clearer and safer.

Hi Daryll,

Thanks again for taking the time to think through this so carefully. I really appreciate how seriously and professionally you are engaging with this idea.

Your distinction makes a lot of sense to me. I agree that a handoff mechanism should not be treated as a replacement for improving compaction itself.

Based on your feedback, I split my thinking into three PR-sized tracks and posted that follow-up on the issue:

1. First, a narrow compaction fix that preserves the recent operational tail as first-party structured context.

1. Then, a bounded project/workspace handoff artifact for cases where a thread has become too large, too valuable, or too risky to keep compressing safely.

1. Finally, a project/thread attachment or transition UX, for cases where a user starts in a general chat and later needs to attach the work to the right project.

I think this framing makes the path much safer: fix compaction continuity first, add handoff only as an escalation path, and treat project attachment as a later UX layer rather than mixing everything into one large change.

Thanks again for your thoughtful feedback. It really helped clarify the implementation direction.

原始邮件

发件人：DZRobo @.*>
发件时间：2026年6月22日 14:55
收件人：openai/codex @.*>
抄送：Lee-take @.>, Comment @.>
主题：Re: [openai/codex] Context compaction loses operational continuity in long Codex tasks; preserve the last 5 operational steps verbatim (Issue #29356)

1dZb1 left a comment (openai/codex#29356)

I think this is a useful complementary direction, but I would distinguish it from the core request in this issue.

The "lossless recent operational tail" should be part of the compaction mechanism itself. It protects immediate continuity inside the same active thread: the agent should not lose the latest user instruction, recent tool/action sequence, touched files, rejected approaches, current verification target, and next step.

A project/thread handoff policy solves a different layer: what to do when the thread has become too large, too valuable, or too risky to keep compressing safely.

I would support a handoff mechanism as an escalation path, but not as a replacement for improving compaction.

The risk is that, if implemented as another agent-written scratchpad or summary, it could recreate the same problem in a different form:

more process artifacts,

more context consumed,

more notes the agent may forget to read,

more user supervision.

So I think the product behavior should be:

Compaction always preserves the recent operational tail losslessly or near-losslessly.

When a thread becomes risky to compress further, Codex can create or update a bounded first-party handoff artifact.

That artifact should be concise, structured, and project-aware, not an ever-growing manual note.

It should point to the real sources of truth: files, diffs, tests, logs, reports, artifacts, and next actions.

It should be used for safe transition to a new thread or phase, not as a substitute for preserving the active operational tail.

In short:

Recent operational tail = protects continuity inside compaction.

Handoff policy = protects continuity when the thread should stop being compressed and transition safely.

I would not want the handoff mechanism to become "another summary the agent writes and then forgets." It needs to be first-party, bounded, and tied to project/workspace state.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you commented.

This issue maps closely to a bounded operational checkpoint profile we have now published from the Liminal side.

Artifacts:

• Profile: https://github.com/safal207/Liminal/blob/main/docs/interop/CODEX_OPERATIONAL_CONTINUITY_PROFILE_V0_1.md
• Schema: https://github.com/safal207/Liminal/blob/main/schemas/codex-operational-checkpoint-v0.1.schema.json
• Conformance fixture: https://github.com/safal207/Liminal/blob/main/fixtures/codex-operational-continuity-conformance-v0.1.json

The profile separates three mechanisms:

historical summary
!= recent operational tail
!= resumable checkpoint

A summary compresses older context. The recent tail preserves up to five structured operational steps. The checkpoint binds that tail to repository identity, Git HEAD, dirty-worktree state, constraints, rejected approaches, touched resources, verification state, and the exact next action.

The main additional boundaries are:

1. Each tail step has a stable reference and digest; the display summary is not the source of truth.
2. Rejected approaches are first-class state and must survive compaction.
3. Resume is idempotent and must not repeat tool calls or side effects.
4. Changed Git HEAD or dirty-worktree state requires revalidation or restart.
5. A completion claim without verification evidence is rejected.
6. The checkpoint carries authority: context_only; prior tool approvals do not silently survive compaction or handoff.

The fixture covers same-workspace continuation, duplicate resume, changed workspace state, broken lineage, a vague-summary regression, loss of rejected approaches, unverified completion, and invalid authorization carryover.

Core principle:

A summary remembers the story. An operational checkpoint preserves the exact place where work can safely continue.

Would a bounded, workspace-bound checkpoint like this be useful as a conformance target alongside the proposed lossless recent operational tail?

Yes, I think this would be useful as a conformance target alongside the proposed lossless recent operational tail.

The distinction between:

• historical summary,
• recent operational tail,
• resumable checkpoint

is exactly the boundary I want to preserve.

The core issue remains that compaction itself should not collapse the active task into a vague summary. The recent operational tail needs to survive compaction losslessly or near-losslessly.

A workspace-bound checkpoint seems useful as an additional validation layer: it can decide whether continuation is still safe by checking repository identity, Git HEAD, dirty state, rejected approaches, touched resources, verification state, and next action.

The most important guardrail for me is that this should not become another manual scratchpad system. If the checkpoint is just another agent-written summary that consumes context and may be forgotten, it recreates the same failure mode.

So I would support this if it is first-party, bounded, generated from actual session/tool/workspace state, and used as a conformance target for safe resume/handoff.

In short:

• lossless recent operational tail = protects immediate continuity inside compaction;
• workspace-bound checkpoint = validates whether resume/handoff is safe;
• historical summary = only compresses older context and should not be treated as the source of truth.

I especially like the invariants around rejected approaches, changed Git HEAD / dirty state, verification evidence, and authority: context_only.

Thanks, safal207. Yes, I think a bounded, workspace-bound checkpoint like this would be useful as a conformance target alongside the lossless recent operational tail.

The part I find especially useful is that it makes the boundary testable rather than only conceptual:

historical summary != recent operational tail != resumable checkpoint

I would map it to the earlier PR-sized tracks this way:

1. Compaction invariant: preserve a bounded recent operational tail losslessly or near-losslessly, ideally from first-party session/tool state rather than from another model-written summary.

1. Resume / handoff validation: use a workspace-bound checkpoint to decide whether continuation is still safe. This is where repository identity, Git HEAD, dirty-worktree state, checkpoint lineage, rejected approaches, touched resources, verification evidence, and exact next action become important.

1. Project/thread transition UX: once the tail and checkpoint model exist, project attachment or safe transition to a new thread can use that state instead of depending on a vague continuation summary.

So I would not see the checkpoint as a replacement for the recent operational tail. I would see it as the stricter resumability contract around it: the tail preserves what just happened, while the checkpoint determines whether it is still valid and safe to continue from that point.

The guardrails I especially like are:

• stable references and digests for tail steps, so the display summary is not treated as the source of truth;
• rejected approaches as first-class state;
• idempotent resume, so retries do not repeat tool calls or side effects;
• changed Git HEAD / dirty-worktree state requiring revalidation or restart;
• completion claims requiring verification evidence;
• authority: context_only, so prior approvals do not silently survive compaction or handoff.

Those cases would make a very useful conformance fixture because they directly test the failure modes this issue is about: vague-summary regression, lost rejected approaches, unsafe resume after workspace drift, unverified completion, duplicate resume, and invalid authorization carryover.

So my answer is yes: this kind of checkpoint seems like a strong conformance target, as long as it remains first-party, bounded, workspace-bound, and derived from actual session/tool/workspace state rather than becoming another manual scratchpad the agent may forget to read.

Thanks — I agree with that separation.

A clean conformance target would treat these as three different first-party artifacts with different authority and lifetimes:

1. Historical summary — lossy and advisory.
2. Recent operational tail — bounded, lossless or near-lossless, sourced from actual user/tool/session events.
3. Resume checkpoint — compact, workspace-bound validation state used to decide whether continuation is still safe.

The checkpoint should not replace the tail and should not carry execution authority. I would keep its authority explicitly context_only, so approvals or permissions from before compaction cannot silently survive resume.

A minimal checkpoint could bind:

• repository/workspace identity;
• Git HEAD and dirty-worktree digest;
• active objective and acceptance criteria;
• current constraints and rejected approaches;
• stable references to touched files, diffs, tests, logs, and artifacts;
• verification evidence already produced;
• exact next action;
• references/digests for the preserved tail steps;
• checkpoint lineage and an idempotency key.

Resume behavior would then be deterministic:

• matching workspace state → hydrate the preserved tail and continue;
• changed Git HEAD or dirty-worktree state → require revalidation or restart;
• missing or inconsistent tail references → fail closed rather than reconstruct from a vague summary;
• repeated resume with the same idempotency key → do not repeat tool calls or side effects;
• prior approvals → never inherited automatically.

The conformance fixtures I would prioritize are:

• valid resume with unchanged workspace state;
• changed Git HEAD blocks continuation;
• dirty-worktree mismatch blocks continuation;
• rejected approach remains preserved after compaction;
• duplicate resume does not repeat a side effect;
• completion claim without verification evidence is rejected;
• prior authorization is not carried across compaction/handoff.

That keeps the distinction testable:

historical summary != recent operational tail != resumable checkpoint

The tail preserves what just happened. The checkpoint decides whether that preserved state is still valid and safe to continue from.

This issue maps very closely to the recovered-evidence and continuation work in LS.

The central distinction may be:

conversation summary
≠ operational continuation state

A compacted summary may preserve the topic, but safe continuation requires a lossless or typed operational tail containing:

• the latest user constraint;
• the current task goal and acceptance criteria;
• the last intended action;
• recent tool events and important outputs;
• files inspected or modified;
• rejected approaches and their reasons;
• unresolved blockers;
• the required verification path.

We recently added a small vendor-neutral envelope that separates:

knowledge recovered
→ valid for this trajectory and continuation
→ enforcement decision

Reference:

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

A possible compaction-tail record could look like:

{
"schema_version": "operational-tail/v0.1",
"trajectory_id": "repo-task-trajectory",
"source_continuation_id": "thread-before-compact",
"target_continuation_id": "thread-after-compact",
"active_goal": "Fix the runtime issue without touching module C",
"active_constraints": [
{
"statement": "Do not apply a local symptom patch before tracing the real data path",
"status": "ACTIVE"
}
],
"rejected_approaches": [
{
"approach": "Patch module A directly",
"reason": "The failure originates in module B"
}
],
"touched_files": [
{
"path": "src/module_b.py",
"last_operation": "EDIT",
"event_ref": "tool-event-184"
}
],
"current_blockers": [
"runtime verification has not yet been completed"
],
"required_next_action": "run the agreed verification command",
"verification_target": "integration test path",
"status": "ACTIVE"
}

The important invariant would be:

«Compaction must not convert active constraints, unresolved blockers, or recent file mutations into vague prose that no longer affects control flow.»

A second useful invariant:

«Resume should preserve the same task trajectory while assigning a new continuation identity.»

That allows the system to distinguish:

same task, resumed after compaction
≠ new unrelated task

A deterministic conformance fixture could test:

1. recent file edits survive compaction with their event references;
2. rejected approach remains rejected after resume;
3. active blocking constraint still produces "DEFER";
4. unresolved verification target remains open;
5. resumed thread receives a new continuation ID;
6. unrelated trajectory cannot inherit the operational tail;
7. narrative confidence does not override missing execution evidence.

This could complement the requested “last 5 operational steps” by making the tail machine-checkable rather than only verbatim text.

Would a small "OperationalTailEnvelope" fixture be useful for testing compaction continuity across CLI, Desktop, and IDE surfaces?

Thanks, this distinction is exactly the core of the issue:

conversation summary != operational continuation state

A summary can preserve what the conversation was about, but safe continuation needs state that still affects the agent's next action.

I agree that a small typed OperationalTailEnvelope could be a useful conformance target, especially if it remains first-party and vendor-neutral rather than tied to any external memory system.

For Codex, I would see the minimal product requirement as:

• preserve the recent operational tail losslessly enough to continue the same task;
• keep active constraints, rejected approaches, touched files, blockers, and verification targets as structured state;
• ensure that this state is consumed by the resumed agent, not merely included as prose;
• prevent unrelated trajectories from inheriting the tail.

The invariant you wrote captures the failure mode well:

Compaction must not convert active constraints, unresolved blockers, or recent file mutations into vague prose that no longer affects control flow.

I also strongly agree with the conformance fixture idea. The most important tests for me would be:

1. a rejected approach remains rejected after resume;
2. an active blocking constraint still blocks the next action;
3. recent file edits remain known with references to the relevant events;
4. unresolved verification remains open until actually executed;
5. resume preserves the same task trajectory while assigning a new continuation identity;
6. unrelated tasks cannot inherit the previous operational tail;
7. narrative confidence cannot replace missing execution evidence.

That would complement the “last 5 operational steps” request by turning it into something testable across Desktop, CLI, and IDE surfaces.

Thanks — this is exactly the boundary I was trying to isolate.

I agree the useful target is a small first-party, vendor-neutral "OperationalTailEnvelope", not an external memory dependency.

The minimal fixture set should prove that after compaction or resume:

• a rejected approach remains rejected;
• an unresolved blocker still blocks;
• recent file mutations remain linked to concrete events;
• pending verification remains open;
• the task keeps the same trajectory but receives a new continuation identity;
• unrelated tasks cannot inherit the operational tail;
• narrative confidence cannot replace missing execution evidence.

The core invariant is:

conversation continuity
!= operational control-flow continuity

I’ll keep the proposed envelope focused on active state that can still change the next action, rather than preserving more narrative context.

This issue's "last 5 operational steps" framing matches the direction I ended up trying as a user-space stopgap, though I agree the real fix should be native.

I put together a small Codex hook package here:

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

It does not preserve the operational tail inside Codex's compacted context. Instead, it externalizes a bounded handoff into the project directory and then forces the resumed agent to read it before continuing:

• PreCompact writes latest.md, latest.json, snapshots, and a small cumulative rollup;
• PostCompact marks the project as needing restore;
• PreToolUse blocks writes/tests/git/service starts/other normal tools while required reads are still missing;
• PostToolUse observes read-only restore tools and clears the gate only after the required handoff/state files have been read.

So it is weaker than what you are requesting here: it is not lossless recent tool history, not a native compact tail, and not a structured first-party continuation envelope. It is closer to a lightweight "make the post-compact agent stop and reread the active handoff before doing more work" mechanism.

I am sharing it because it may help people who need a temporary workaround today, especially for long local coding sessions. I would still strongly prefer Codex to have a native structured operational tail / continuation state, because that could preserve recent constraints, touched files, rejected approaches, pending verification, and provenance more reliably than a hook can.

Also, practical caveat: the generated continuity files can contain task/session context and command summaries, so the repo documents adding .codex-compact-continuity/ to .gitignore and cleaning it up when no longer needed.

@Sakiyary this is a useful stopgap, and the boundary you drew is important: it enforces a restore obligation, but it does not turn the handoff into authoritative execution history.

The strongest part of the design is the gate:

PostCompact -> restore required -> normal tools blocked -> required state read -> execution resumes

That is materially safer than merely writing a scratchpad and hoping the resumed agent remembers to consult it.

I would make the handoff envelope carry a few explicit fields so the workaround remains inspectable:

• schema_version;
• source session / project identifier;
• snapshot creation time and reason;
• bounded operational-tail entries;
• referenced file paths plus content or git digests where available;
• pending verification target;
• restore-required file list;
• handoff digest.

The resumed agent should still treat that envelope as continuity evidence, not as authority to claim that an action definitely occurred. Claims such as “this patch was applied” should resolve against git state, diffs, tool logs, or another durable source of truth.

So the separation is:

• your hook package provides a practical restore gate today;
• a native Codex continuation envelope should preserve the recent operational tail structurally;
• durable execution provenance should remain independently verifiable.

Thanks for documenting the privacy caveat as well. Project-local continuity files are useful, but they should be local state by default, not accidental repository artifacts.

@safal207 wrote in https://github.com/openai/codex/issues/29356#issuecomment-4839841507: this is a useful stopgap, and the boundary you drew is important: it enforces a restore obligation, but it does not turn the handoff into authoritative execution history.

Thanks, this is a helpful framing. I agree with the separation you described: this hook package can provide a practical restore gate today, while the handoff should remain continuity evidence rather than authoritative execution history. Claims about applied patches, passing tests, or completed commands should still be verified against git state, file contents, tool logs, or fresh command output.

I updated the package in that direction: the handoff now carries a structured envelope with schema version, source project/session, creation reason, bounded recent tail, referenced files/digests where available, pending verification, restore-required files, suggested reads, and a handoff digest.

One small clarification on "local state": I intentionally keep the continuity files project-local and visible, rather than hidden in a global directory, because users should be able to inspect and remove what the tool stores. The package writes a nested .gitignore, and the README strongly recommends adding the continuity directory to the project .gitignore as well.

We converted the continuity discussion into a vendor-neutral, executable RFC rather than another scratchpad proposal:

RFC-001 — Verifiable Continuation Envelope
https://github.com/safal207/pythiaLabs/blob/main/standards/agent-continuity/RFC-001-VERIFIABLE-CONTINUATION-ENVELOPE.md

Machine-readable contracts:

• envelope schema: https://github.com/safal207/pythiaLabs/blob/main/standards/agent-continuity/schema/continuation-envelope.schema.json
• restore-results schema: https://github.com/safal207/pythiaLabs/blob/main/standards/agent-continuity/schema/restore-results.schema.json
• reference validator and 17 conformance tests: https://github.com/safal207/pythiaLabs/tree/main/standards/agent-continuity/conformance
• reviewed merge: https://github.com/safal207/pythiaLabs/pull/208

The key implementation split is:

1. Compaction emits a bounded continuation envelope containing the active objective, recent operational tail, current constraints, touched artifacts, rejected paths, pending verification, blockers, provenance, and required restore checks.
2. Resume produces separate restore results proving which required material was actually read and which artifact digests/receipts were independently verified.
3. Normal execution remains fail-closed until the gate passes. Missing reads, schema drift, digest mismatches, untrusted authority, existence-only execution evidence, or unresolved blockers cannot become RESUMABLE.

This preserves the issue's requested recent operational tail while avoiding two unsafe shortcuts:

• treating an agent-written summary as proof that an action occurred;
• allowing restored file/tool/memory content to silently regain instruction authority.

The implementation is transport-neutral, so Codex could store the envelope natively inside its compaction/runtime layer rather than requiring project files or user-maintained notes.

I'd add one more test, aimed at the consumed-not-just-included point.

The fixtures so far mostly check the machinery... envelope present, required reads done, gate blocks until restore. What they can't check is whether the restored state changes the next decision. I've watched an agent re-read a rejection and then propose the rejected thing an hour later anyway, reworded just enough that no pattern-match would catch it. A gate can block "retry A" when A is literally matchable; a re-proposal usually isn't.

So, a behavioral fixture: resume, then put the agent in a spot where the rejected approach looks like the right call. Pass = it declines and points at the rejection. Fail = it re-proposes, however phrased.

In my runs the wording of the stored rejection decided this more than anything about survival. "Rejected: X, because Y. Do not retry X" held. "We went with B after considering X" did nothing.

I want to add a user-facing Codex App workflow case that makes this issue especially difficult to manage.

Observed workflow

A long-running Codex App thread had become reliable at producing art assets after many rounds of user correction. The thread had accumulated both explicit project constraints (MD prerequisites, frozen decisions, visual rules) and implicit working knowledge (accepted/rejected outputs, recurring failure patterns, and the user's preferred production process).

The agent then suddenly drifted from the main direction and failed to follow MD prerequisite requirements. This happened immediately after switching to the 1.5x/Fast setting, although there is not enough evidence to claim that Fast mode caused the context loss. The important point is that the user had no reliable way to know whether the thread had compacted, whether constraints had weakened, or whether the deviation was a temporary model error.

Codex also warns that starting a new thread may lose experience accumulated in the existing thread. This leaves users in a difficult position:

• staying in the long thread risks silent compaction-related drift;
• starting a new thread risks losing corrections and learned workflow;
• the user cannot reliably judge when continuity has degraded;
• manually creating and maintaining handoff MD files is burdensome and defeats the purpose of an agentic product.

AGENTS.md is necessary but not sufficient here. It can preserve explicit hard rules, but it does not automatically preserve the full history of accepted/rejected outputs, implicit corrections, current production state, or why previous approaches failed.

Requested product behavior

Please add an App-level conversation health and verified continuation workflow:

1. Show when automatic compaction has occurred and how many times it has occurred.
2. Proactively warn when the system has reduced confidence in preserving earlier constraints or operational state.
3. Offer a user-controlled Continue in a new thread action rather than forcing users to decide blindly.
4. Build the handoff from the full available transcript plus project files, not only from the latest compacted summary.
5. Preserve, at minimum:

• durable project and MD constraints;
• latest task state and next action;
• accepted and rejected decisions/examples;
• recent user corrections;
• prohibited approaches and reasons;
• required reference files and their read order;
• completion and verification criteria.

1. Before resuming work, have the replacement thread restate these items and automatically compare its understanding with the source thread/handoff snapshot.
2. Block destructive or production actions when required files or constraints were not successfully transferred.

This is different from simply auto-creating a replacement thread after N compactions (as discussed in #22641). The request is for a visible, user-approved, validated continuation mechanism and an early warning that does not require the user to understand context-window internals.

For non-technical users, deciding when to compact, when to switch threads, and how to write a lossless handoff should be product responsibility, not a manual workflow imposed on the user.