Codex App incorrectly treats completed Steered conversation prompts as current tasks after compaction when a goal is active

What version of the Codex App are you using (From “About Codex” dialog)?

26.623.81905

What subscription do you have?

ChatGPT Pro 20x

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex App incorrectly treats a completed Steered conversation prompt as the current task after context compaction when a goal is active.

The issue is not just that Codex sometimes refers to older context. The narrower problem is this:

A goal-continuation turn is running.
The user inserts a one-off Steered conversation prompt during that turn.
Codex handles that Steered conversation prompt.
Later, after context compaction, Codex may treat that already-handled Steered conversation prompt as if it were the current task again.

In the persisted transcript and compacted model-visible history, the Steered conversation prompt may look like an ordinary role: "user" response item. If replacement_history carries that message near the end without an explicit handled/closed semantic that is visible to the next continuation, the old prompt may receive too much priority as if it were still the current task.

There are two observable failures:

Wrong final answer target: Codex does useful work for the current goal continuation, but the final visible answer responds to the old Steered conversation prompt.
Wrong next task selection: Codex actually plans around the old Steered conversation prompt again and repeats work that was already done.

This appears to be a state tracking issue in the app harness around active goals, Steered conversation prompts, and context compaction.

A sanitized transcript shape is below. All values are synthetic placeholders.

A goal continuation may appear as user-like internal context:

{
  "type": "response_item",
  "payload": {
    "type": "message",
    "role": "user",
    "content": [
      {
        "type": "input_text",
        "text": "<codex_internal_context source=\"goal\">Continue working toward the active thread goal...</codex_internal_context>"
      }
    ],
    "internal_chat_message_metadata_passthrough": {
      "turn_id": "goal-turn-1"
    }
  }
}

A Steered conversation prompt inserted during that running goal turn may be persisted as an ordinary user message with the same turn id:

{
  "type": "response_item",
  "payload": {
    "type": "message",
    "role": "user",
    "content": [
      {
        "type": "input_text",
        "text": "Steered prompt about Topic X"
      }
    ],
    "internal_chat_message_metadata_passthrough": {
      "turn_id": "goal-turn-1"
    }
  }
}

After Topic X is handled, a later compaction may still preserve that completed Steered conversation prompt as a plain user message near the tail of replacement history:

{
  "type": "compacted",
  "payload": {
    "replacement_history": [
      {
        "type": "message",
        "role": "user",
        "content": [
          {
            "type": "input_text",
            "text": "Steered prompt about Topic X"
          }
        ],
        "internal_chat_message_metadata_passthrough": {
          "turn_id": "goal-turn-1"
        }
      },
      {
        "type": "compaction"
      }
    ]
  }
}

The app should keep an equivalent state marker or other model-visible semantic that means "this Steered conversation prompt has already been handled and must not become the current task again." For example, the shape could be:

{
  "source": "steered_conversation",
  "scope": "interrupt_current_turn",
  "handled": true,
  "handled_by_turn_id": "goal-turn-1",
  "must_not_become_current_task": true
}

The exact field names above are illustrative, not observed existing fields. The important invariant is that compaction must preserve an equivalent handled/closed semantic across the model-visible continuation boundary.

Without that distinction, after compaction the model-visible state may effectively look like this:

{
  "active_goal_continuation": true,
  "recent_user_like_message": "Steered prompt about Topic X",
  "old_steered_prompt_is_marked_handled": false
}

That can make an already-handled mid-turn Steered conversation prompt look like the current task.

What steps can reproduce the bug?

A minimal reproduction shape:

Start a long-running Codex App thread with an active goal.
Let Codex begin a goal-continuation task, Task Y.
While Task Y is running, use Steered conversation to insert a one-off instruction or question, Topic X.
Let Codex handle Topic X and continue the active goal.
Do not submit another ordinary user prompt.
Continue the goal long enough for context compaction and another goal continuation to occur.
Observe one of these outcomes:
- Codex works on Task Y, but the final response answers or summarizes completed Topic X.
- Codex plans around completed Topic X again and repeats work for it.

This reproduction is narrower than generic stale-prompt behavior:

{
  "requires_active_goal": true,
  "requires_mid_turn_steered_conversation": true,
  "requires_steered_prompt_handled_before_failure": true,
  "requires_no_later_ordinary_user_prompt": true,
  "usually_triggered_or_amplified_by_compaction": true
}

Subagent notifications may make the issue easier to trigger if they are also represented as model-visible user messages, but the essential problem is the handled-state of a Steered conversation prompt across goal continuation and compaction.

What is the expected behavior?

A Steered conversation prompt should be a turn-scoped interruption. After Codex handles it, it should not remain eligible to become the current task again.

Expected harness behavior:

{
  "steered_conversation": {
    "event_type": "steer",
    "scope": "current_turn",
    "priority": "interrupt",
    "after_handled": "closed"
  },
  "compaction": {
    "preserve_handled_state": true,
    "may_keep_completed_steer_for_history": true,
    "must_not_promote_completed_steer_to_current_task": true
  },
  "final_response": {
    "owner": "current_turn_id",
    "must_not_answer_a_completed_steer": true
  }
}

A completed Steered conversation prompt may remain in transcript history for auditability, but it must not compete with the active goal checkpoint or any later real user instruction.

Additional information

Accuracy note from source inspection:

turn_steer / steer_input attaches the new input to the active turn and returns the active turn id, which matches the observed same-turn behavior.
Internal goal context is represented as a user-role model-context fragment.
replacement_history is persisted as response items and is the history future prompts may carry after compaction.
The suggested handled_by_turn_id / must_not_become_current_task fields are only one possible fix shape; I have not observed those exact field names as existing persisted fields.
There are related source tests for steered input around mid-turn compaction, but this report is specifically about active-goal continuation and stale task ownership after compaction.

Potential harness-level fixes:

Serialize Steered conversation as a distinct event type, or as a message with explicit model-visible metadata such as source="steered_conversation", scope="current_turn", and handled=true once handled.
Preserve the handled/closed state through compaction.
Ensure compacted.payload.replacement_history must not make an already-handled Steered conversation prompt appear to be the current task.
Bind final visible response ownership to the current turn id.
Treat internal goal continuation context and asynchronous notifications as structured non-user events or lower-priority metadata, not as ordinary user prompts competing with real user intent.

Regression tests that would likely catch this:

[
  {
    "name": "completed_mid_turn_steer_not_treated_as_current_after_compaction",
    "setup": ["active_goal", "mid_turn_steer", "steer_handled", "compact", "goal_continue"],
    "assertion": "planner_continues_goal_not_completed_steer"
  },
  {
    "name": "final_response_owned_by_current_turn",
    "setup": ["active_goal", "completed_steer", "new_goal_work_performed"],
    "assertion": "final_answer_summarizes_current_turn_work"
  },
  {
    "name": "replacement_history_preserves_handled_steer_state",
    "setup": ["steer_handled", "compact"],
    "assertion": "completed_steer_cannot_be_current_task"
  }
]

Related issue family: #29811, #30767, #14318, #14667, #24225, and #8648.

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

Powered by Codex Action

I can confirm the same failure mode on macOS, so this does not appear to be Windows-specific.

Environment:

Codex Desktop on macOS 26.5.1 (Build 25F80)
Embedded Codex CLI: 0.144.5
Model: gpt-5.6-sol, reasoning effort high
No custom compact_prompt or experimental_compact_prompt_file

Sanitized event sequence from an affected long-running turn:

The primary implementation task was still unfinished and had a concrete next action.
An earlier mid-turn Steered conversation request had already been completed and acknowledged.
Codex resumed the primary implementation.
Automatic context compaction occurred.
Immediately after compaction, Codex answered the already-completed steer again.
It then emitted task_complete, leaving the primary implementation checkpoint unresolved.

The persisted event shape was effectively:

unfinished primary checkpoint
→ context_compacted
→ response repeating completion of an already-handled steer
→ task_complete

The affected long-running turn contained 9 steering messages and 6 automatic compactions. Earlier compactions in the same run sometimes resumed correctly, so the failure appears intermittent rather than an unconditional compaction failure.

In the final compacted replacement_history I inspected, prior user-role messages remained explicit, while the fact that the steer had already been handled—and the current primary checkpoint—did not have equivalent explicit durable state. That is consistent with the issue's handled/closed-state hypothesis, although it does not by itself isolate whether the bug is in compaction generation, post-compaction task selection, or completion ownership.

A useful regression assertion may therefore be stronger than “do not answer the old steer”:

after compact(active primary task + handled steer):
  selected task == active primary task
  task_complete is forbidden until the primary terminal condition is satisfied

I have omitted the original thread ID, repository, paths, code, and task-specific content because they are proprietary, but can provide additional redacted structural statistics if useful.

Additional sanitized reproduction from Codex CLI on Linux, with an active persistent goal.

Environment and scope

Installed CLI checked during the investigation: codex-cli 0.153.4.
A long-running conversation with a persistent goal and one-off user requests interleaved with goal continuations.
The behavior was first noticed after updating the CLI. There has not been a controlled before/after comparison, so this does not establish that 0.153.4 introduced it.

Observed sequence

A one-off request for a small command-line utility was completed. After each of two later compactions, the assistant answered that already-completed request again.

The following timestamps come from a read-only inspection of local rollout event metadata; all are UTC on 2026-09-05:

Timestamp (UTC)	Event
01:28:32.396	User requests the small utility.
01:30:08.214	Assistant delivers the original final answer.
02:34:58.936	`compacted` event.
02:35:23.945	Assistant repeats instructions for the completed utility in a `final_answer`.
03:16:01.442	Another `compacted` event.
03:17:10.958	Assistant repeats the utility instructions again in a `final_answer`.

Thus, the completed side request was answered twice more, about 25 seconds and 70 seconds after the respective compactions, while the primary goal remained unfinished.

Expected behavior

A handled side request should remain completed across compaction and goal continuation. The next action and final answer should belong to the active goal or a genuinely new user request, not a previously completed interruption.

This is consistent with the handled-state/task-selection failure described in this issue, but the timing alone does not distinguish a compaction-summary defect from post-compaction task selection or another harness/model issue.

No raw transcript, repository details, local paths, thread identifiers, or task-specific data are included.

Observed the same behavior in Codex Desktop with a remote Linux session reporting Codex version 0.154.0.

During a long-running active goal, I submitted an implementation-related question once. Codex answered it and continued working. After subsequent context compactions, it repeatedly answered that already-handled question again.

Findings from the local session log:

The original question was submitted only once.
Across 22 subsequent compaction records, the question remained the last explicit user message in the replacement history. Explicit goal-continuation messages and previous assistant replies were absent from that history, apart from any information carried by the opaque compaction summary.
For each of the five most recent compactions inspected, the first assistant commentary returned to the already-answered question.
Useful implementation work continued between these repetitions; this was not a complete execution stall or simply the UI displaying the same message.

Expected behavior: continue the active goal without repeatedly treating an already-answered question as a fresh request.

Raw logs are omitted because they contain private project and conversation data. These observations do not establish what information was retained inside the opaque compaction summary.

Confirmed a more severe version of this failure on Codex Desktop for macOS.

During an active turn:

Codex was executing the current assignment and had launched several subagents.
Three subagents completed; one remained active.
Automatic compaction occurred without any new owner message.
Immediately afterward, Codex resumed from an already-handled steering message sent several hours earlier.
It incorrectly claimed the owner had explicitly instructed it to stop and checkpoint. No such instruction existed.
It interrupted the remaining subagent, abandoned the current assignment, persisted a false waiting state, and reported that false state to another task.
Its final response answered the stale message instead of completing the active turn.

This means the bug can affect more than response selection: it can alter live task control, interrupt delegated work, and corrupt durable state.

A regression test should verify that an already-handled steering message cannot regain control after compaction, that active work remains active, and that completion or waiting states cannot be recorded from stale instructions.

Controlled evidence of asymmetric context retention, checked October 1, 2026.

I reproduced a contributing explicit-history loss in the installed Windows engine, first with codex-cli 0.158.0-alpha.2.1 and then again with the updated 0.159.2 on October 1, using the actual app-server and goal extension. The test used a separate synthetic home and a loopback fake Responses endpoint, bypassing the local proxy. No production transcript or account credential was used.

The sequence was: answer a setup question; start an active goal for Task Y; inject Topic X with a real same-turn turn/steer; emit a synthetic assistant commentary that handles Topic X; return a tool call and usage above the compaction threshold; compact and capture the resumed inference before any new ordinary human input.

Explicit item	Input to compaction	Input to resumed inference
Hidden active-goal fragment	Present	Absent
Mid-turn Topic X user message	Present	Present
Original assistant commentary handling Topic X	Present	Absent
Compaction item	Not yet produced	Present

An ordinary continuation without compaction retained the goal and assistant answer. A genuinely new human request identical to the earlier request survived as a separate occurrence; deleting or deduplicating matching human text would violate that control.

Source boundary: goal continuation is an internal user-context fragment that intentionally does not parse as a visible user message. Both retention paths use that visible-message parser:

Local compacted_user_message admits visible TurnItem::UserMessage only.
Remote-v2 is_retained_for_remote_compaction_v2 admits user messages through visible-turn parsing and rejects assistant-role messages.

Those links are pinned to upstream 819efd72732adf600c833c6b026fcfbd1e8968b7, inspected October 1. The source matching the earlier 0.158.0-alpha.2.1 engine is 0d9c7cbfa6cf1489f55a8a9542b75ddd2c061807; the published rust-v0.159.2 tag points to ff6aec96948b70d94983af2641a6b67c94faeff5. This connects the runtime observation with a concrete client retention rule and supports the goal-loss finding in #32922.

Repair investigation: a local candidate based on 7b88d09d61b862e229832e446c87863ade890b48 retains recognized goal fragments and bounded original assistant text while preserving role, content parts, phase and provenance. It prioritizes existing user/goal input before spending remaining space on replies; a historical goal must not crowd out a newer human correction. It excludes generated compaction outputs and does not infer that every commentary closes a request. All 128 selected affected compaction tests pass, including actual mid-turn steering, long recorded replies, repeated compaction, correction priority, image budgets and existing resume/rollback cases. This is local candidate evidence, not an installed fix or a complete issue regression.

The candidate standalone app-server built successfully and completed the same controlled goal-extension sequence as installed 0.159.2. The resumed explicit goal fragment and original handled commentary match their pre-compaction items exactly, including commentary phase. The steer remains once, and the new identical human request appears separately. Ordinary-continuation controls also pass for both executables. These runtime checks still use fake model output; they establish the repaired input boundary, not planner or final-answer behavior.

Limits: the fake endpoint returned an opaque placeholder rather than a genuine encrypted summary. The test cannot reveal what a real summary retains, compel a live model to repeat Topic X, or establish handled/closed semantics. Retaining original context is a concrete repair direction, but a message's commentary phase alone does not prove the interruption is finished. I would not close #30859 on these results.

The remaining behavioral acceptance should use genuine compaction and assert both outcomes from this issue: the next selected action continues Task Y, and the final answer reports Task Y's newly observed result. Completion/waiting transitions must not derive from the historical steer. Then a newer correction and a genuinely new identical request must remain actionable.

Later validation on October 1, 2026: digest-verified published0.159.2 CLI and code-mode helper assets match the corresponding installed executable payloads after excluding only the PE checksum and Authenticode certificate table. This establishes the release-payload comparison, not a reproducible build or certificate-trust claim.

Genuine model tests through the existing custom Responses route requested Sol/high, with effective upstream identity not independently verified. Both the patched current-main candidate and an unmodified engine from the same base passed the bounded local-summary probe. Both also completed native remote-v2 compaction, installed a real nonempty opaque item with a matching response ID, used that item in subsequent generation, and reported a fresh Task Y measurement. New correction and identical-new-question controls remained actionable.

The behavioral bug did not reproduce in these bounded tests. The first remote diagnostics ended the quick-answer turn and continued the goal in a new turn. A stricter follow-up now uses the installed0.159.2 engine and requires a real commentary answer, subsequent native remote-v2 compaction, and fresh Task Y measurement in the same still-running goal turn. Its no-compaction control and compact trial both pass the fresh-Y, correction and identical-new-question checks.

In the stricter compact trial, native request/response traces bind the real compaction trigger, returned opaque item, matching persisted response ID, installed history and subsequent generation. The explicit goal disappears1â†’0 and the actual answered commentary disappears1â†’0, while the old steer remains1â†’1. Opaque summary contents remain unknown. Task Y still completes correctly without replaying the old question. Thus genuine same-turn input loss is confirmed, but it does not by itself establish the cause of the reported behavioral bug.

These tests request Sol/high through the existing custom Responses route. One medium-effort control ended its turn before the required exposure; it is inconclusive, and no medium compact trial followed. Final transmitted-wire and effective upstream model identity remain unobserved. All results are native-client evidence in isolated synthetic homes, not desktop qualification. The candidate has not been installed. These synthetic results alone do not establish a behavioral reproduction or causal repair. I would keep this issue open.

Additional qualification on October 1: independent review confirmed that the earlier strict test's permanent base instructions retained a sensor-audit direction after compaction. One follow-up omitted that override and used the ordinary Codex base with task-neutral external-access restrictions. Native setup and continuation show identical base hashes and no Task Y/audit direction in developer/base channels. Genuine same-turn compaction again removes the explicit goal and answered commentary while retaining the steer, but the installed engine still completes fresh Y and both new-user controls. This addresses that instruction-coverage gap only; opaque contents remain unknown and the repeated-answer symptom is still unreproduced. No further synthetic model-test batch is planned.

The repair now also builds against published0.159.2 source as local 0.159.2+reply-retention.1:124 affected checks pass. Four additional retry/advice variants in the128-test current-main selection are absent from this earlier release base. The preserved release CLI passes26 integrity/startup/explicit-retention checks with isolated fake Responses output, including exact goal/reply content and phase preservation and separate identical-new-request handling. These establish that this release package contains the input repair; they do not prove live model behavior, desktop integration or a causal fix. No installed app change was made. Matched behavioral case validation remains necessary.

A narrow real-chat observation on October 1, 2026 (UTC): I also caught the investigation chat returning to an already-handled storage request. The request arrived at 09:22:41.618 and received a substantive final answer at 09:34:18.505. The later native goal continuation at 11:55:39.495 concerned fixing this issue and submitting its analysis. A genuine compaction at 12:42:07.050 persisted 14 replacement-history items: 12 user messages, zero assistant messages, zero explicit goal fragments, one surviving historical storage request and one opaque item. Storage-oriented commentary followed 6.323 seconds later. The opening was corrected within the same turn; bounded message enumeration found no new human storage request between compaction and that recovery.

Exact original records and hashes were independently checked locally. This is a narrow wrong-target commentary/recovery observation, not a repeated final answer or false goal-completion finding. Historical-request reselection is an interpretation; the opening sentence alone cannot exclude ancillary storage work. The counts describe explicit persisted replacement history, not opaque-summary contents or the final transmitted input. There is no matched candidate comparison for this case, so it corroborates the asymmetric retention concern without establishing patch efficacy. The issue should remain open.

Repeated-compaction synthetic reproduction (October 1, 2026; independently qualified bounded native case)

A single bounded native run of the installed Windows CLI now captures a complete repeat of an already-handled mid-turn request after five genuine compactions. The explicit goal was to audit six batches, one per native goal turn. A mid-turn steer requested only the jq filter selecting .name from .items; the engine completed that answer before any pressure. It then correctly measured and reported batches 1 through 4. After batch 5 inventory and its fifth compaction, it again emitted .items[].name as a final-answer item while the original goal remained active and only four of six measurements existed. There was no intervening ordinary human request. The observer stopped on that affirmative final item, so batch 5 measurement, batch 6 and later ordinary-input controls were not run; cancellation at cleanup is not false goal completion.

The data entered through a dedicated direct dynamic-tool namespace, while native goal tools and code-mode host configuration were preserved. All five actual compaction requests included all 1,500 inventory rows and both endpoints. All 17 native inference starts retained the same ordinary-base segment hash and selected model/effort. Request/response IDs, returned opaque item, installed checkpoint, persisted compaction and first subsequent generation are joined across all five boundaries. This is one trajectory, not five spliced single-compaction tests.

The original run result is preserved as PROBE_ERROR: the first reader incorrectly required one persisted turn-context record per turn. Release source deliberately persists the reference context again after compaction and its optional world-state baseline. The saved run has the initial context plus one identical post-compaction refresh in each affected turn. The repaired reader validates the initial task/context/goal order and the exact source-supported refresh batch, rejecting missing, duplicate, foreign, changed or displaced records. Eleven focused source/ordering/consumer checks pass. Re-adjudication is saved separately and reports an observed baseline failure with valid native exposure, independently accepted after source/raw-record checks and the eleven focused checks; all 175 original run files remain unchanged.

This observation does not prove the candidate repair, full desktop integration, opaque semantic contents, final physical wire, effective upstream backend or billing. The captured final answer is affirmative replay, not an instruction quoting or rejecting the filter. No blanket handled/closed marker or repeated-text suppression is proposed: a genuinely new identical user request must still be answered, and a fresh correction must still execute. A single matched candidate run then used the same method, seed, data, model, effort and limits, with only the pinned engine executable changed. Its incomplete outcome is described below.

Candidate comparison remains incomplete

The first pinned release-based retention candidate preserved the original visible assistant answer in actual post-compaction model inputs; the installed baseline had zero such visible answer items at all five boundaries. This verifies an input-retention difference, not the semantic contents of either opaque summary. The candidate still measured and reported only four batches before seven compactions exceeded the frozen six-compaction cap. Its original verdict is UNEXPOSED, not a pass, a replay failure or a verified fix; fresh correction and identical-new-request controls were not reached. No automatic retry, threshold increase or model/seed search was performed.

The candidate's retained generated goal reminders accumulate across turns: actual compaction requests contain two, three, four, five and eventually six separate host-tagged goal.internal_context reminders. Their combined visible text grows from 13,696 to 41,096 characters, before ordinary base and other context. Extra compactions also occur without a new inventory release. This is a concrete boundedness concern in the proposed retention approach; source/usage diagnosis is in progress. Any correction must distinguish host-generated steering from real user goal changes and preserve original replies, provenance, chronology, fresh corrections and genuinely new identical user requests. The production desktop and configuration remain unchanged.

Second source variant: qualified primary improvement, separate resumed controls

The first candidate's reminder-growth defect is now corrected in local 0.159.2+reply-retention.2, built from the same published 0.159.2 release source. Native automatic goal inputs carry a history-only identity derived from the authoritative goal ID, exact objective and token budget; changing usage counters are excluded. Only recognized host-generated goal continuations receive this identity. Compaction supersedes older trusted reminders of the same unchanged goal with its latest complete reminder. Different goal instances, objective/budget changes, ambiguous or inherited reminders and controls stop that supersession. Original assistant answers and genuine human requests retain their recorded content, phase, provenance and chronology. This does not retroactively trust old unmarked reminders or suppress identical human requests.

Independent source review identified and resolved an ambiguity-barrier defect, with exact local/remote falsifiers. All 32 current-version focused checks and 387 history/protocol compatibility checks pass, together with scoped lint and the Windows CLI build. A single deliberately accepted matched primary run retained the original method, seed, 1,500-row inventories, model/high selection and finite limits; only the pinned engine executable changed.

That actual native primary interval completed all six fresh measurements and batch reports through six genuine compactions, with no replay of the already-handled jq answer, no ambiguous jq reference and no premature goal-complete observation. Every first subsequent model input retained exactly one latest complete goal reminder (6,849–6,850 characters) and the original recorded assistant answer. Actual full inventory replies, fresh sensor values, model outputs, API completions, returned opaque items, installed checkpoints and persisted history are joined. The same ordinary base and selected native model/effort remained consistent. Independent review qualified this primary interval from the untouched saved artifacts. This is a bounded comparison, not a statistical or universal effectiveness claim.

The original whole-run verdict remains UNEXPOSED: after the sixth report the goal was still active, and another automatic turn raced the terminal pause. The observer refused to admit later human controls while that turn was in progress. Pausing stops future goal continuation but does not abort an already-admitted turn; pause acknowledgement alone does not establish idle. Cleanup interrupted that tail. No goal-completion or uninterrupted whole-run pass is claimed, and no rerun of the primary, cap increase, seed/model search or verdict rewrite followed.

The two later human controls were instead qualified separately on a verified copy of the closed synthetic home's saved state. Only the copy's indexed rollout location was relocated; the original primary files stayed unchanged. Actual resume selected the copy's writer, same paused goal and idle state. Both human starts explicitly restored the original empty environment selection. Two preliminary copied-control exposures are preserved as probe errors: a Windows extended-path comparison stopped before inference, and a later cold-resume workspace-tool difference was caught before any sensor reply. The corrected bounded tail leaves the frozen capability guard unchanged.

The qualified cold-resume tail used four native inferences, two real human turns, one fresh direct sensor call and zero additional compactions. The correction consumed a newly returned sample/reading and reported them; a later genuinely new identical jq request was answered normally. Independent raw-request/transport/output/persistence review accepted both controls. Native model/effort, ordinary base and exact permitted tool schema match the primary; the latest opaque checkpoint identity and original saved-history prefix are preserved. These separate controls cannot convert the original run into an uninterrupted full-run pass.

The source patch and compiled candidate are available locally. Production desktop, installed defaults and configuration remain unchanged. Full desktop integration, final physical wire, effective upstream backend and opaque semantics remain unqualified; this evidence supports the proposed retention repair without declaring the entire reported issue fixed. The issue should remain open pending target validation.

Follow-up to my October 1 investigation: I have now implemented, built and installed a native engine repair on Linux, with a reproduced baseline failure and a passing bounded candidate run. This is a local repair, not an upstream release fix, and I would keep this issue open pending broader validation.

Current build and observed mechanism

This follow-up uses codex-cli 0.162.0-alpha.17.2 with desktop package 26.1007.21434-1 on Arch Linux. It is separate from the earlier Windows 0.159.2 experiments. The source base is 740e5af33c71225640e0c1c1555c514c2c93ab74.

In the affected history, remote-v2 compaction retained the original human steer while dropping the explicit assistant reply and goal context. The old request could therefore reappear in explicit history without the original evidence that it had already been answered. This describes the visible client history; the contents of the opaque summary remain unknown.

Native changes

In core/src/compact_remote_v2.rs, retain eligible original assistant text and classified goal context/control records alongside genuine user messages. Preserve original roles, content, phases, provenance and ordering, with bounded retention and whole-record admission. This does not mark every commentary as a completed request or suppress repeated human text.
In ext/goal/src/extension.rs, contribute the current persisted goal lifecycle state and objective when constructing turn context, while respecting newer accepted goal controls whose persistence may still be pending or failed.
In history reconstruction and the local thread store, recover missing original dialogue when loading an eligible legacy user-only v2 checkpoint. Recovery requires the exact original human anchor, an indexed successfully completed source turn, original assistant records after that anchor, and consistent ordering. The source read is bounded to a plain JSONL span of at most 16 MiB. Missing or contradictory evidence causes recovery to abstain; stored conversation history is not rewritten.
Add a host-only v2_dialogue_retention_version marker to newly produced checkpoints. This prevents legacy recovery from undoing intentional omissions made by the new retention policy. A regression check also prevents a later completed reply from being moved back across an earlier mid-turn checkpoint and duplicated.

The main invariant is that an old answered request remains historical, while a genuinely new identical request is still actionable.

What has actually passed

An unmodified-engine control reproduced an answer to the old request during later goal continuation without a new human request.
In an isolated native OLD-to-NEW checkpoint-resume test, the patched executable restored the exact original completed assistant reply into the first model request, including its original identity/content/phase. The old executable omitted it.
One qualifying real-model candidate trajectory crossed two genuine remote compactions, preserved the original answer and goal context in the observed native inputs, continued fresh goal work without replaying the answer, and then answered a byte-identical question submitted as a distinct new human request.
Focused source checks and independent review covered retention, goal lifecycle, legacy recovery, ordering and the raw native traces. An earlier run that exceeded its request allowance remains inconclusive; it was not relabeled as a pass.
The exact tested executable was installed and verified running after a desktop restart. The bounded post-restart observation of the affected session showed ordinary continuation without the sampled old-steer repetition.

Remaining limits

The real-model result is one bounded candidate trajectory, not repeated statistical effectiveness or proof that every stale-task failure is fixed. The recorded post-restart affected-session window contained no new compaction, so it does not establish sustained post-compaction behavior in that live session. Opaque-summary semantics and terminal goal-completion correctness are not established by these checks.

I also installed a separate local package-update safeguard: it preserves the qualified binary and source patch outside the app package, restores the repair only for exact known engine/app identities, and refuses unqualified builds on the managed launch path. That is local deployment protection, not automatic forward-porting or evidence of compatibility with future releases.

The source patch and validation artifacts remain local; no upstream PR or publicly downloadable patched binary is being claimed here.

Navigation Menu

Repository navigation

Codex App incorrectly treats completed Steered conversation prompts as current tasks after compaction when a goal is active #30859

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Repeated-compaction synthetic reproduction (October 1, 2026; independently qualified bounded native case)

Candidate comparison remains incomplete

Second source variant: qualified primary improvement, separate resumed controls

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Codex App incorrectly treats completed Steered conversation prompts as current tasks after compaction when a goal is active #30859

Description

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Jul 1, 2026

LemonCANDY42 commented on Jul 20, 2026

annawoodard commented on Sep 5, 2026

axelcursive commented on Sep 18, 2026

lukeivers commented on Sep 20, 2026

Parm-1 commented on Oct 1, 2026

Repeated-compaction synthetic reproduction (October 1, 2026; independently qualified bounded native case)

Candidate comparison remains incomplete

Second source variant: qualified primary improvement, separate resumed controls

Parm-1 commented on Oct 12, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions