Proposal: Treat context compaction as a trust-boundary transition for long-running mutable tasks

Summary

For long-running Codex tasks that can modify files or other external state, automatic context compaction should optionally be treated as a trust-boundary transition rather than an ordinary invisible continuation point.

I am proposing an opt-in fail-closed mode in which an observed context-compaction event:

1. checkpoints the current execution state;
2. revokes further mutation authority;
3. persists that denial across restart/resume; and
4. requires explicit state re-verification before mutations are allowed again.

This is complementary to proposals that try to improve post-compaction continuity. If continuity can be restored reliably, Codex should continue. But when the runtime cannot guarantee that the active execution state survived compaction intact, continuing to mutate the workspace is riskier than stopping.

Why this matters

A long-running agent can cross a context-compaction boundary after it has already:

• inspected files;
• changed code;
• run tests;
• rejected approaches;
• reached a verification or release stage;
• accumulated acceptance criteria and stop conditions.

After compaction, a partially reconstructed state can lead to failure modes such as:

• repeating completed work;
• reopening resolved decisions;
• losing the exact completion condition;
• treating an earlier state as current;
• making new mutations from stale assumptions;
• reporting unexecuted verification as complete.

The key distinction is that context continuity and mutation authority do not need to be the same thing.

If Codex is uncertain about its restored state, it can still explain what happened, inspect durable evidence, and recover. What should be optional is the right to continue modifying external state before that recovery is verified.

User-space reference implementation

I implemented a small user-space guard to test this model against the real Codex app-server notification stream on Windows.

Environment used for the live validation:

• Codex CLI/app-server: codex-cli 0.147.0-alpha.6.5
• platform: Windows
• real Codex executable SHA-256: fb5c760e14cf8fe86e12e49e8a3e7f237af06082d6b9fe1e411e463b7229c916

In the independently re-read live run:

• raw app-server JSONL: 39 lines, 0 parse errors;
• item/started + contextCompaction: exactly 1;
• guard firing: exactly 1;
• checkpoint create/write: 1 / 1;
• persistent deny lock created;
• checkpoint terminal state: COMPACTION_GUARD_TRIPPED;
• detected=true;
• task_complete=false;
• post_compaction_work_allowed=false.

The guard then rejected mutation in both relevant states:

• same-process post-compaction mutation attempt: rejected, exit 73;
• mutation attempt after restart: rejected, exit 73;
• restart path did not start a new app-server child before the denial.

The controlled target remained byte-for-byte unchanged across the live run:

• pre file count: 42;
• post file count: 42;
• content diff: 0;
• metadata diff: 0;
• pre tree SHA-256: 1c2c0486700f8f75bb2f63a00fd975a1a0515c4a63e4cefaa7cb59cc9ad77cea;
• post tree SHA-256: 1c2c0486700f8f75bb2f63a00fd975a1a0515c4a63e4cefaa7cb59cc9ad77cea.

The live validation was closed read-only after the original validation session itself hit context compaction during final evidence review. The successful run was not promoted until the external evidence, raw event stream, checkpoint, deny lock, process termination, and hashes were independently re-read.

Proposed product behavior

An opt-in policy could look conceptually like:

RUNNING_MUTABLE
  -> context compaction observed
  -> CHECKPOINTED_UNVERIFIED
  -> mutation_authority = false
  -> explicit recovery / durable-state re-verification
  -> RUNNING_MUTABLE

Possible configuration semantics:

context_compaction_policy = "continue" | "pause" | "fail_closed"

For fail_closed, I would expect at least:

• a first-class pre/post compaction runtime event;
• durable checkpoint identity;
• explicit task_complete state;
• explicit mutation-authority state;
• persistent denial across restart/resume;
• a supported recovery/re-verification transition;
• clear UI status explaining why writes are blocked.

This does not require disabling compaction. It only separates a context-management event from authorization to continue mutating external state.

Relationship to existing reports

This proposal appears related to, but is not the same as:

• #36712 — automatic compaction can destroy active task context;
• #35935 — post-compaction task-state regression and repeated work;
• #29356 — preserve recent operational continuity;
• #34963 — preserve a configurable raw tail during compaction;
• #25660 — post-compaction resume-state regression.

Those issues primarily ask Codex to preserve or restore enough state to continue. This proposal adds a safe failure mode when that guarantee is not available.

A useful invariant would be:

unverified_post_compaction_state != mutation_authority

Expected benefit

This would not eliminate hallucinations generally. It would constrain one specific and observable failure class in long-horizon mutable workflows: unsupported continuation after a context-compaction boundary.

For tasks involving builds, release preparation, evidence generation, repository modification, or other externally persistent effects, an opt-in fail-closed boundary would provide a deterministic alternative to silently trusting reconstructed execution state.

pip install codex-rescue==0.1.0a5
codex-rescue doctor <path-to-rollout.jsonl>