Compaction during a send_message_to_thread-triggered turn can revive an obsolete instruction and produce an incorrect execution report

Environment

Codex Desktop on Windows
Bundled CLI: 0.153.0

Summary

A task delivered through send_message_to_thread was received and partially executed correctly. After automatic mid-turn compaction, the receiving agent reverted to an older, already-completed instruction instead of finishing the current task.

Its final response then incorrectly reported that no task execution had occurred, despite successful tool results and files created earlier in the same turn.

Why `send_message_to_thread` is used

Long-running work is often split across existing specialist threads. A coordinator delegates one current task to a thread that already holds the relevant project context, then waits for that thread's result. This avoids recreating context, busy polling, and keeping one oversized turn alive while unrelated work runs elsewhere.

For this workflow to be reliable, the latest delegated task must remain the receiving thread's current authoritative instruction across automatic compaction. Source attribution may remain metadata, but it must not cause the instruction to be treated like disposable command output.

Observed Sequence

The following task labels are illustrative, not original prompt text:

A thread previously completed Task A.
Another thread delivered Task B through send_message_to_thread.
The receiving agent acknowledged Task B and performed several authorized actions.
Automatic context compaction occurred before Task B's final reporting was complete.
Without a new instruction reinstating Task A, the agent resumed following Task A.
The final response described the obsolete task and contradicted execution evidence from the current turn.

Local Evidence

Inspection of the local rollout showed:

The incoming Task B instruction was recorded as a function_call_output associated with send_message_to_thread.
Successful execution records existed before compaction.
The replacement history retained the older Task A instruction as a visible user message.
Task B's original cross-thread message was absent from the verbatim replacement history.
An opaque compaction item was also present. Its contents cannot be inspected, so this does not establish that Task B was entirely absent from the compressed summary.

The observable failure is that the post-compaction continuation followed an obsolete instruction and produced an inaccurate execution report.

Requested Resolution

Please make a delegated task durable through one of these equivalent semantic designs:

Restore send_message_to_thread delivery as a first-class user message in the receiving thread, while keeping sender/source attribution in separate metadata; or
Persist the delivery as a dedicated first-class delegated-instruction record that compaction treats as current semantic input, not as ordinary tool output.

In either design, compaction should preserve:

the latest delegated instruction and its stable message identity;
completed actions and their results from the current turn;
remaining work, constraints, and the requested delivery target;
the fact that superseded or completed instructions are no longer current.

An older visible user prompt must not regain authority merely because the current instruction arrived through cross-thread delivery.

Current Workaround and Evidence

A local workaround sends the same text through the desktop/app-server message path as a first-class user message with a stable clientUserMessageId, instead of recording it as tool output. Across seven subsequent natural mid-turn compactions, the latest delegated task remained the last user instruction in replacement history and each receiving thread continued the correct task. No objective reversion was observed in those samples.

This is not evidence that the product bug is fixed, and it does not prove the complete root cause. It does indicate that preserving the delegated task's semantic role across compaction is an effective mitigation.

Expected Behavior

Compaction should preserve the current cross-thread task, completed actions, remaining work, and applicable constraints. An already-completed instruction should not regain authority over the active task.

Final reporting should remain consistent with actions already performed in that turn.

Related Reports

Goal mode replays the last manual steer on later continuation turns #27894: previously handled instructions becoming actionable again after compaction.
Context compactization forgets current mission #11054: compaction causing the agent to return to earlier tasks.

This report specifically concerns send_message_to_thread input. Whether it shares the same root cause requires investigation.

Privacy

Original screenshots, prompts, task outputs, identifiers, and raw logs are intentionally omitted.

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

Powered by Codex Action

Adding two independent macOS observations of the same failure pattern, on a newer bundled CLI. This is additional evidence, not confirmation of a shared root cause.

Environment

Codex desktop: 26.901.51231
Bundled codex-cli 0.153.4
macOS (exact OS build omitted; not captured in this report)
Visible runtime metadata for both failed turns: gpt-6-astra / xhigh; service tier not recorded.

Observed sequence

The task descriptions below are sanitized paraphrases, not original prompts.

A receiving thread was given a narrow delegated task through send_message_to_thread: review 40 fixed event records and write one candidate table. It acknowledged the correct task and reported progress. A mid-turn contextCompaction event then occurred. The subsequent final response answered an older, unrelated topic; the required output file did not exist at that point.
A separate receiving thread was given a narrow independent-review task. It also initially acknowledged the correct task. Following a mid-turn contextCompaction event, it answered an older recovery-planning topic instead, without the requested review verdict.

Both turns completed, but neither completion satisfied its current delegated assignment. No new instruction had reinstated the older topic.

Evidence boundaries

The App records display the incoming dispatch as functionCallOutput / send_message_to_thread. This does not by itself establish its inference-message role or priority.
A fresh local CLI features listing reported remote_compaction_v2=true; the exact branch taken by the two existing failed turns is unverified.
The actual compaction-summary contents and immediate post-compaction model inputs were not available for inspection.
A changed-method retry (checkpoint first, save small batches) completed all 40 records, but had zero compaction events. It therefore does not demonstrate that the compaction failure is fixed.
We have not tested the app-server workaround described in the issue.

Unconfirmed source-code lead

The public rust-v0.153.4 compact_remote_v2.rs has build_v2_compacted_history and is_retained_for_remote_compaction_v2; ordinary FunctionCallOutput items are not directly retained as raw items by that filter. This does not prove their content is omitted from the compaction output, and a matching version number does not establish binary identity with the desktop build.

Please investigate preservation of the latest authenticated delegated instruction, its constraints, completed actions and remaining deliverable across genuine mid-turn compaction. A regression should contrast a no-compaction baseline with actual mid-turn compaction, and verify that older paused/completed tasks are not revived. If recovery is impossible, an explicit blocked result is preferable to silently completing the wrong task. Arbitrary tool output should not be promoted into trusted instructions as a workaround.

No email address, account information, conversation/task identifiers, local paths, business material, screenshots or raw logs are included.

Reproduced again on Windows Codex Desktop with bundled codex-cli 0.153.4 on September 10, 2026 (America/Chicago).

Sanitized timeline, in CDT (UTC−05:00):

23:14:38: A coordinator delivered a new investigation through cross-task delegation, recorded as function_call_output with a codex_delegation wrapper. The receiver acknowledged the correct assignment.
23:25:20: The receiver reported a concrete finding relevant to that investigation and said it was checking the remaining evidence.
23:28:26: A genuine mid-turn compacted record appeared. The visible replacement history retained the earlier user instruction to wait for further instructions; the current delegation's original input was not present verbatim. An opaque compaction item was present, so this does not establish what its summary encoded.
23:28:31: The receiver ended with an acknowledgment of the previous completed task and said it was waiting for further instructions, instead of delivering the active investigation.
23:37:50: The user had to remind it to follow the prior assignment.

PR #44659 was merged earlier that day, but this reproduction occurred on the older 0.153.4 desktop backend. It is not evidence of a regression after that PR. The PR appears to propagate turn_trigger metadata for delegated usage; its diff does not establish a fix for preservation of the active delegated instruction across compaction. Could maintainers confirm whether #42695 is covered by that change or needs a separate fix?

No raw logs, original assignment text, project paths, account details, or task identifiers are included.

Additional evidence: this failure was absent during experimental context management and returned with conventional compaction

Environment: Windows, Codex Desktop 26.908.4834.0, running bundled codex-cli 0.154.0-alpha.6.2.

I want to clarify an important difference in my observed experience: while my sessions were using experimental context management, I did not observe the obsolete-instruction replay or unrequested early stopping described in #42695. These behaviors reappeared after the sessions returned to conventional compaction.

The local records support this before/after observation.

During the experimental workflow, the agents saved checkpoints, explicitly called new_context, and recovered their state through notes and history retrieval. I audited eleven explicit transitions across three tasks on September 11. Their subsequent visible behavior continued the expected work and respected the latest applicable instructions. No obsolete-instruction replay or unrequested stopping was observed in those transitions. Where a new pause instruction was actually given, it was followed correctly.

On September 13, the affected sessions instead recorded opaque summary-compaction items without the preceding new_context/checkpoint transition sequence. Shortly afterward, a coordinator and a delegated worker revived previously fulfilled pause instructions despite having acknowledged and acted on newer resume instructions.

The worker still recognized its current work item, but its continuation and reporting conditions reverted. In the coordinator’s case, both the older pause instruction and the newer direct user resume message remained visible in replacement history, yet it subsequently marked its unfinished goal as blocked.

This is relevant to Tibo’s September 12 announcement, which says an opt-in context management experiment was disabled because it could cause early stops or replies to older messages. In my observed sessions, the experimental workflow was the period without this failure; recurrence was associated with the return to conventional compaction.

The local experimental_mode setting remains enabled. I cannot independently verify the server-side experiment state or its exact transition time. This is an observational comparison, not a controlled same-input A/B test. The opaque compaction contents also cannot be inspected, so absence from visible replacement history does not establish complete omission from the compressed context.

The public 0.154.0-alpha.6.2 release includes the corresponding change from PR #44659 through a backport. That PR describes turn-trigger propagation for delegated usage attribution; this report concerns preservation and application of the current instruction and task state.

Could maintainers clarify whether the experiment shutdown was intended to address #42695, what behavior existing opt-in sessions should now use, and whether the conventional compaction path needs a separate fix for completed or superseded instructions becoming active again?

Regression coverage should include genuine compaction after an acknowledged resume instruction and verify that obsolete pause conditions remain inactive.

Additional Windows reproduction, observed September 15–16, 2026. This report was prepared with Codex from local rollout inspection at the user's request. Project contents and identifiers are omitted; A/B below are sanitized task labels.

Environment at investigation

Windows Codex desktop package: 26.908.9136.0
Running bundled executable: codex-cli 0.154.0-alpha.6.2
These versions were checked after the incident; they are not a verified version history for every earlier turn.

Observed evidence

The same long-running receiving thread had an old direct user message stopping an earlier experiment A. Later authorized assignments to continue work B arrived via send_message_to_thread, represented in the rollout as named function_call_output items with namespace codex_app. The receiver acknowledged and executed B.

All five inspected compacted.replacement_history records retained the same old stop as their last explicit user message. Later delegated assignments were absent as separate verbatim items. An encrypted compaction item was present, so this does NOT prove those assignments were absent from the compressed representation.

The latest incident has this sequence (UTC, September 16):

17:31:53: the current assignment B arrived via cross-thread delivery.
18:07:32: the receiver reported progress on B and said it would save the remaining outputs and finish verification.
18:08:54: mid-turn compaction occurred.
18:08:54: a local SessionStart reminder was actually injected as a developer message, explicitly saying the old stop was not a new command.
18:08:58: the receiver announced that it was stopping experiment A.
18:09:02: it read a persisted task-state note explicitly identifying B as current and the old stop as inapplicable.
18:09:22: it nevertheless ended with a stopped-work report.

No new user stop appeared between that compaction and the final response. Similar obsolete-stop responses followed two September 15 compactions. A September 16 17:41 compaction was followed by correct continuation, so this is not a deterministic failure at every compaction. The local reminder/checkpoint approach did not prevent the latest failure.

Source-code lead, not a verified root-cause patch

At public commit 43354d0f61c1bda3eff26decaf13276bb57039e7, core/src/compact_remote_v2.rs::is_retained_for_remote_compaction_v2 retains certain AgentMessage/Message items but returns false for FunctionCallOutput. The public TUI's dynamic_tools.rs::start_turn intentionally delivers delegated input through TurnStartParams.tool_output to preserve tool authority. This is consistent with the observed difference in verbatim retention, but the exact source revision of the installed alpha build and contents of its encrypted compaction item have not been verified.

Please investigate preservation of the latest authorized delegated assignment, its source/order/scope, and already-completed work across repeated compactions. A product-level fix should preserve provenance rather than promote arbitrary tool text to user authority. A regression case should cover old stop-A → newer delegated continue-B → repeated compaction → continue B, and separately confirm that a genuinely new stop-B is honored.

No raw logs, original prompts, screenshots, local paths, or task/account identifiers are attached.

Additional macOS occurrence observed on September 29, 2026. Prepared with Codex from inspection of the affected chat history at my request. Task A/B below are sanitized descriptions.

Environment

Installed Codex desktop app at investigation: 26.924.22138, build 11645, macOS. Version/build read from the app bundle after the incident; the executable version used by the failed turn was not independently verified.
No deliberate compaction experiment was run.

Observed sequence

The receiving chat had previously answered a direct user question about a repository method's name (Task A).
A coordinator sent a different, read-only issue-status follow-up through send_message_to_thread (Task B). The app displayed it as “Sent by ChatGPT from another task.”
The inspected turn records the incoming request as functionCallOutput, name send_message_to_thread, namespace codex_app, with a delegation wrapper.
The assistant correctly acknowledged Task B and successfully read the issue's status and comments.
A contextCompaction event appears in that same turn.
Immediately afterward, the assistant announced an investigation of the method from Task A, read repository source, and produced another answer to the already-answered naming question. It did not deliver the requested Task B status/next-action summary.
No new user instruction reinstating Task A appears in that turn. The new final answer exists in the recorded history and matches what the UI displays; this is an actual wrong-task continuation, rather than merely a duplicated rendering of an old message.

Evidence limits

The history establishes the ordering and the incorrect continuation. It does not establish the contents of the compaction summary, the full post-compaction model input, whether the delegated request was omitted from that input, or the precise implementation defect. The displayed tool-output record alone does not prove its inference-time role or priority. No controlled reproduction or fix validation has been performed.

This closely matches this issue's delegated Task B → mid-turn compaction → completed Task A sequence. A regression test should verify that the current delegated assignment remains active and that the final response addresses it, even when an older direct user question has already been answered.

No original prompts, screenshots, raw logs, project names, issue keys, local paths, or private chat/account identifiers are attached. This same occurrence is also being cross-referenced on #42131; it should not be counted as two incidents.

Additional Windows occurrence — 3 October 2026. Two existing specialist chats received authorized review requests through cross-task messaging, began the requested work, then reverted to older instructions after recorded mid-turn contextCompaction events. These were existing chats, not newly spawned subagents.

Observed sequence from task-history inspection:

Reviewer A explicitly confirmed authorization and began the requested checks. After compaction it instead said no additional work had been authorized and that it would remain on hold. Affected turn: 07:56:49–08:03:20 UTC.
Reviewer B began its review and reported progress. After compaction it returned to an older, unrelated tooling discussion and ended without the active review result. Affected turn: 07:55:54–08:06:03 UTC.

Those times are turn boundaries, not exact compaction timestamps. No new user stop instruction appeared between compaction and the stale response in either affected turn. Both reviews were completed after manual reminders. This was therefore not simply failure to deliver a request: each receiver acknowledged and started it.

Evidence limits: this establishes event ordering and wrong-task continuation, not the underlying implementation defect, the complete post-compaction model input, or a model-specific cause. Exact incident app/backend versions and a Feedback ID are not included in this update; the older version in my September report should not be treated as today's version. No raw logs, private task IDs, original review material or project paths are attached.

This closely matches the cross-task request → work begins → compaction → obsolete instruction sequence in this issue. Related symptoms are also tracked in #42611, #8648 and #16042. These are two incidents, not separate incidents for each linked issue.

Expected behavior: retain the current authorized request, completed work, remaining work and reporting destination across compaction, while continuing to honor genuinely new stop instructions. The practical impact is silent unfinished reviews: the requesting chat waits while the receiver appears idle or finished, and I have to notice and intervene.

Corroborating compaction-triggered stale-assignment failure on macOS, observed October 4, 2026 (Asia/Manila).

Environment: Codex workflows in the desktop app; installed ChatGPT host version 26.930.21537, build 12776. The exact embedded Codex component/model version was not collected.

The coordinator assigned an existing QA thread a current browser acceptance task through send_message_to_thread. The receiving thread acknowledged it and executed the correct task:

Signed into the intended local application.
Opened the existing approved case.
Submitted an explicit current-record read.
Inspected the current-record outcome.
Submitted a bounded recorded-history read.
Inspected that outcome.
The retrieved thread transcript then contains a contextCompaction item.
The next visible assistant final answer was only "Open Surfacing" — a navigation-link response unrelated to completing or reporting the active acceptance task.

The current turn completed without a reported execution error. No new human instruction canceled or replaced the assignment between the correct browser actions and that final response. The coordinator had to redispatch the current assignment and explicitly instruct the thread to preserve and inspect its completed reads rather than repeat them.

A separate validation thread in the same workflow also began its current assignment but returned an unrelated old browser-session response; after redirection it completed the actual validation. The user reports this stale-instruction pattern repeatedly after compactions. This has happened multiple times already while working on this ONE project, across established specialist threads; it is not a single isolated occurrence or a comparison between unrelated projects. Repeated coordinator interventions have been necessary to restore the current assignment.

A subsequent browser continuation was rejected by safety review citing a previous stop instruction despite the currently resumed assignment. This is an additional observed stale-stop symptom; the precise relationship to the compaction/delegation failure needs investigation.

Impact: unfinished acceptance, specialist threads going idle, repeated manual redispatch, extra time and compute, and risk of repeating already-completed operations. Correct tool execution before compaction does not ensure correct post-compaction reporting or continuation.

Expected behavior: preserve the latest delegated assignment, its completed operations/results and remaining work through compaction. Do not revive an obsolete link-only/login/stop assignment. Post-compaction reporting must accurately reflect operations already performed.

This report is intentionally sanitized: no customer information, screenshots, credentials, private project paths, thread identifiers or raw session logs are included. The explicit contextCompaction-to-unrelated-final sequence was observed using the desktop thread-reading tool; the internal replacement history was not inspected.

Additional macOS reproduction observed on October 4, 2026. This confirms that the failure is still present in a newer Desktop/CLI build.

Environment:

Codex Desktop 26.930.31730, build 12947
Bundled codex-cli 0.160.0
macOS 26.7 (25G229), arm64
Model: GPT-5.6 Sol, high reasoning effort

Sanitized persisted sequence (UTC):

22:42:40  a new send_message_to_thread assignment is received
22:42:47  the receiving agent acknowledges the correct assignment
22:42:51  it begins a repository check for that assignment
22:43:53  contextCompaction occurs in the same turn
22:44:06  the first post-compaction assistant message switches to an
          unrelated, previously handled PDF-signing task
22:44:11  a second delegation supplies precise data for the current assignment
22:46:23  the user intervenes after the agent continues the stale task

There was no new user instruction between the correct pre-compaction work and the stale post-compaction continuation. The second delegated update was persisted after compaction, but it still did not restore the current task automatically.

The receiving agent later acknowledged that it had continued the wrong neighboring context. The current assignment resumed only after the user explicitly told it to reread the transferred task.

This adds two useful points to the existing report:

The failure remains reproducible with Desktop 26.930.31730 / CLI 0.160.0.
A fresh second delegation after compaction may be insufficient to recover task authority once the stale task has been revived.

Expected behavior: the latest delegated assignment, completed work, remaining constraints, and subsequent updates must remain authoritative across compaction. If the continuation state is ambiguous, the agent should stop and request clarification before switching objectives or performing tool actions.

No conversation identifiers, task identifiers, project names, local paths, private prompts, screenshots, or raw logs are included.

Additional Windows reproduction observed on 8 October 2026: the same existing receiving chat lost the current cross-thread task twice after mid-turn compaction.

Environment captured after the incidents

Running desktop package: OpenAI.Codex 26.1002.7124.0 (Windows Store installation; the ChatGPT host process runs from this package).
Running bundled executable: codex-cli 0.162.0-alpha.2.
Windows 11, 10.0.26300, x64.
Model recorded in both affected turns: gpt-6.1-sol, reasoning effort xhigh.

Sanitized observed sequence (UTC)

Attempt	Turn window	Observed outcome
1	04:05:42–04:11:02	A coordinator used `send_message_to_thread` to request an already-authorized website implementation task. The receiver acknowledged it and performed startup/source checks. After a recorded mid-turn compaction, it answered an older question about GA4 and Clarity and completed the turn without the implementation deliverable.
2	04:15:00–04:34:19	The coordinator explicitly restored the current task, explained the previous failure, supplied a working UTF-8 command and required a durable execution checkpoint. The receiver resumed the correct work, edited source files and ran 42 passing tests across 11 test files. At 04:33:24.524 a `compacted` record was written; the subsequent continuation again answered the old GA4/Clarity question and completed the turn instead of finishing or accurately handing over the implementation.

Both turns completed with error: null in the task-status API. In the second attempt, 14 modified/new local files remained, while the written checkpoint was still an early startup snapshot. Git HEAD had not advanced and no new production release was recorded. Actual partial progress therefore existed, but the terminal response did not report it or identify the unfinished work.

The incoming current tasks are persisted as function_call_output records containing a codex_delegation wrapper. For the second compaction, inspection of the visible replacement_history found no such delegated-task tool-output record. The opaque compaction item is not inspectable, so this is not a claim that the active task was entirely absent from the compressed summary, nor proof of the complete root cause.

A local Python stdout encoding error occurred during the first attempt. That error was explicitly fixed and verified before the second attempt; the repeated task reversion occurred after the receiver had successfully read the same workbook/PDF and completed real code changes and tests. The encoding issue alone therefore does not account for both observed failures.

Expected behavior

Preserve the active delegated instruction, unfinished work, successful changes/tests and applicable authorization across compaction. An already-answered historical question should not replace the current task. If execution stops, report the real checkpoint and remaining blockers rather than silently closing with an unrelated answer.

Mitigation being used

The user has requested that execution continue in the coordinator chat under a direct human instruction. Existing changes and test evidence are being preserved and reviewed before resuming; the affected chat is retained for provenance.

This is two observed failures in one long-lived chat, not a measured overall failure rate or evidence that every chat is corrupted. No passwords, account data, project identifiers, native session IDs, full prompts, raw logs, hidden reasoning or opaque summary contents are included here.

Additional Windows occurrence on 2026-10-12 (Asia/Seoul; UTC timestamps below), checked against saved events by the affected chat and a separate reviewing chat. This is one observed occurrence, not a controlled reproduction or measured failure rate.

Environment

Incident turn metadata: gpt-6-astra, reasoning effort ultra, both before and after compaction.
Installed versions checked on 2026-10-13: desktop package OpenAI.Codex 26.1007.2314.0; bundled codex-cli 0.162.0-alpha.17.2; Windows 11 x64, build 10.0.26300.
Those installed versions are investigation-time observations, not independently verified executable versions for the incident.

Sanitized sequence from the same turn

Task A was an already-answered infrastructure-status question. Task B was a new, unrelated, advice-only instructions review sent by another existing chat.

2026-10-11T22:23:00.635Z: Task B arrived as function_call_output, namespace codex_app, name send_message_to_thread, containing a readable delegation wrapper.
2026-10-11T22:23:06.248Z: receiver correctly acknowledged B and then read the relevant instructions.
2026-10-11T22:24:46.442Z: a compacted record appeared.
2026-10-11T22:24:55.422Z: receiver announced Task A instead, then used a subagent and executed a fresh read-only remote status query for A.
2026-10-11T22:26:29.265Z: receiver returned another answer to A. The requested B consultation was not delivered.

There was no new user instruction reinstating A. This was new wrong-task execution, not a duplicate rendering of the previous answer. No file or server-configuration changes were observed.

Evidence limits

The replacement history contained 47 user messages, three developer messages, and one opaque encrypted compaction item. The old A question remained explicitly present; B was absent as a standalone readable item. The compacted resume metadata still identified the turn trigger as app_tool_send_message.

The opaque item's contents are unknown, so this does not prove B was absent from the compressed state or establish the underlying defect. The latest authorized assignment, its scope and provenance should survive compaction; an already-completed human question should not silently become current again.

No raw transcripts, original prompts, private project paths, chat identifiers, credentials, or opaque payloads are included.

Additional Windows observation: the initial summary preserved the delegated task, but recovery still revived a completed instruction

This adds a distinction to the existing report, rather than reporting a controlled reproduction or a confirmed root cause.

Environment and scope

Codex Desktop on Windows. The saved incident session metadata reports 0.162.0-alpha.17.2; the exact running Desktop package/app-server binary and effective retention feature state were not independently established for that turn.
The incident used a configured API-provider integration. The provider label alone does not establish the actual inference backend or which component caused the failure.
The observations below come from one saved receiving-thread event sequence, independently inspected after the incident. No artificial compaction or paid replay was performed.

Observed sequence

Task A was a local instruction-refresh request. Task B was a subsequently authorized, bounded implementation assignment delivered by another existing chat.

A had already produced a successful final response and a task-completion event.
B arrived through send_message_to_thread, persisted as a named function_call_output. The receiver read the source human authorization, acknowledged B, recorded it as started with an absolute deadline, and sent a startup receipt.
The first readable compaction summary correctly identified B as active, explicitly distinguished it from another instruction refresh, and preserved its scope, unfinished work and deadline.
The corresponding visible replacement history retained the earlier A user message but did not retain B's original tool-delivered request as a standalone item. Side metadata still referenced the delegated delivery. This is asymmetric visible retention, not proof that B disappeared from all compressed state.
Recovery reread an older handoff snapshot and announced that it would only refresh instructions. A subsequent readable summary then encoded that incorrect task selection.
Even after reading the started-assignment record and deadline again, the receiver persisted the obsolete A interpretation and finished with A's response format, saying there was no unfinished work while failing to account for B.

No new direct user instruction reinstated A between B's arrival and this incorrect completion. The delivery succeeded and the receiver initially understood the current task; this is not merely a missing-message or empty-turn incident.

What this establishes, and what it does not

The observable failure is post-compaction selection of a completed request over a current, source-verified assignment, followed by inconsistent state/reporting.
The first summary preserved B correctly. Therefore, "the first summary entirely forgot the task" is not a sufficient explanation for this occurrence.
Visible replacement-history asymmetry is a plausible contributing condition, not an isolated or proven cause. We did not capture the complete post-compaction inference request, inspect opaque compaction data, or prove a specific client, model or provider defect.
We inspected actual pre-incident presentation of relevant recovery rules. This does not prove that every instruction file was fully understood, or that a project-level refresh can enforce Desktop recovery behavior.

Local mitigation and acceptance limits

Our project now requires reconciliation of the active request/event, processing slot, terminal state, pending delivery and original deadline before restoring a reading cursor. Within the activity-bound local reader path, ownership and snapshot checks reject terminal-refresh rereads and delivery bound to a different request. These checks depend on the supplied record and do not independently authenticate the event or enforce every tool path.

These are project-level checks, not a Desktop patch. Local synthetic/CLI regressions pass, but an agent can bypass this reader and the host is not globally intercepted. A subsequent bounded message test had no compaction; it does not demonstrate a real post-compaction fix. Desktop retention-path verification and a genuine post-compaction acceptance test remain outstanding.

Expected behavior: preserve and reconcile the current authenticated assignment, completed actions, remaining deliverable, reporting destination, deadline and genuinely new stop instructions. Completed historical requests must not become current solely because they remain visible. If recovery is ambiguous, report the specific conflict instead of silently completing the wrong task.

No original prompts, screenshots, raw transcripts, hidden reasoning, opaque payloads, private identifiers, local paths, business details or identifying hashes are attached.

Additional macOS occurrence observed on October 18, 2026. This adds a provenance-and-recovery variant to the delegated-task replay described here.

Environment checked after the incident

ChatGPT/Codex Desktop host: 26.1013.40934, build 20770
Bundled codex-cli 0.163.0-alpha.10.2
macOS 26.7.1 (25G241), arm64
These versions were read after the incident and are not asserted as a verified executable history for the failed turn. The model and reasoning setting were not independently captured.

Sanitized observed sequence

A user gave a current instruction B in a coordinating chat and approved its next implementation step.
The coordinator delivered B to an existing receiving chat through cross-task delegation. The receiver acknowledged B, investigated it, and produced the requested implementation contract.
A contextCompaction event occurred in that receiving turn.
Immediately afterward, the receiver revived an older, already-handled user instruction A. It sent A back to the coordinator as the current direct user instruction, stopped B, and treated previously granted approval for B as unavailable.
The coordinator supplied exact chronological evidence of the newer user instruction B and asked the receiver to reread the coordinating chat. The receiver initially rejected that correction, saying its latest direct user message was still A and that another chat could not cancel it.
After a fresh explicit correction and reread of the coordinating chat, the receiver acknowledged that A was stale and resumed B.

No new user message in the receiving chat reinstated A between compaction and the replay. The first stale-task transition is directly adjacent to the recorded compaction event. This establishes the event ordering, not the complete post-compaction model input or the underlying implementation defect.

Additional impact

This occurrence propagated false provenance across chats: a historical instruction was described to the coordinator as a fresh/current direct user command. The receiver then defended that provenance even when given identifiers and timestamps for a newer human instruction. Recovery required another explicit correction plus rereading the source chat.

The result was interrupted authorized work, redundant cross-thread messages, repeated authorization checks, and additional time/compute. No production or third-party mutation occurred in this occurrence.

Expected behavior

Preserve current-instruction chronology, handled/superseded state, and original provenance across compaction.
A retained historical user message must not become current merely because newer work arrived through delegated/tool-delivery state.
When a coordinator supplies verifiable evidence of a newer human instruction, rereading the source chat should reconcile the active task instead of preserving the stale one.
If authority remains ambiguous, stop before tool side effects and report the conflict explicitly.

Suggested regression: handled direct instruction A → newer human-approved B → B delivered through send_message_to_thread and acknowledged/worked → mid-turn compaction → verify B remains current. Then provide source-chat chronology for B and verify that the receiver cannot continue to classify A as the latest instruction.

No conversation, turn or message identifiers, original prompts, project names, local paths, private business details, screenshots, raw logs or opaque compaction contents are included.

Additional occurrence observed on 2026-10-21 (Asia/Tokyo) in Codex Desktop on Windows.

Observed sequence

A human requested a concrete local-model evaluation in a coordinating chat, including a preferred inference backend, a temporary agent-provider setting, and conditional adoption if speed and conversational quality met the stated requirements.
The coordinator forwarded that authorized task through send_message_to_thread to the existing worker chat.
The worker acknowledged the correct evaluation and provider-configuration task in its first commentary, read project state, and called read_thread to inspect the source instructions.
A contextCompaction item then appeared in the same receiving turn.
The next commentary changed the objective to explaining whether the existing model was oversized for the application.
The worker read additional documentation for that different question and ended with a conceptual answer about model size and application roles. It did not deliver the requested evaluation or provider configuration.

The coordinator subsequently inspected the completed turn using read_thread. The acknowledged assignment, compaction marker, changed commentary, and unrelated final answer were all visible in that one turn. No new human instruction changing the objective was visible between those events in the inspected turn.

Expected behavior

The acknowledged, current delegated assignment and its remaining work should survive compaction. If execution is blocked, report that specific blocker; do not complete the turn by answering a different historical/conceptual question.

Impact and evidence limits

This caused an authorized task to stop after intake and unrelated investigation, requiring human detection and corrective coordination. The initial acknowledgment looked like progress, but was not evidence of execution.

This is one observed incident, not a deterministic fresh-session reproduction. The ordering is confirmed in the returned transcript; the opaque compaction contents, complete post-compaction model input, and internal root cause were not inspected. It may be a task-state/provenance, compaction, or model-continuation issue; this report does not establish which component is responsible.

Platform: Windows desktop. Exact installed app build, bundled CLI version, and selected worker model were not independently captured for this occurrence.

This sanitized report was explicitly requested by the affected user. It excludes original prompts, project names, local paths, private thread/turn identifiers, account information, credentials, raw logs, and full conversation transcripts.

Compaction during a send_message_to_thread-triggered turn can revive an obsolete instruction and produce an incorrect execution report #42695

Description

Environment

Summary

Why send_message_to_thread is used

Observed Sequence

Local Evidence

Requested Resolution

Current Workaround and Evidence

Expected Behavior

Related Reports

Privacy

Activity

github-actions commented on Sep 4, 2026

345180376-web commented on Sep 6, 2026

Environment

Observed sequence

Evidence boundaries

Unconfirmed source-code lead

FrankHZ commented on Sep 11, 2026

HS7097 commented on Sep 13, 2026

IvanKashitskii commented on Sep 16, 2026

Environment at investigation

Observed evidence

Source-code lead, not a verified root-cause patch

andriyo commented on Sep 29, 2026

Environment

Observed sequence

Evidence limits

javadavado-svg commented on Oct 3, 2026

blockjacc commented on Oct 3, 2026

phoenixweiss commented on Oct 3, 2026

bobbyleeweiwei-bobby commented on Oct 8, 2026

Environment captured after the incidents

Sanitized observed sequence (UTC)

Expected behavior

Mitigation being used

realgyeongminnoh commented on Oct 13, 2026

Environment

Sanitized sequence from the same turn

Evidence limits

RongNianXin commented on Oct 14, 2026

Environment and scope

Observed sequence

What this establishes, and what it does not

Related upstream work and remaining question

Local mitigation and acceptance limits

phoenixweiss commented on Oct 18, 2026

Environment checked after the incident

Sanitized observed sequence

Additional impact

Expected behavior

kilalice commented on Oct 21, 2026

Observed sequence

Expected behavior

Impact and evidence limits

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Why `send_message_to_thread` is used