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:

1. A thread previously completed Task A.
2. Another thread delivered Task B through send_message_to_thread.
3. The receiving agent acknowledged Task B and performed several authorized actions.
4. Automatic context compaction occurred before Task B's final reporting was complete.
5. Without a new instruction reinstating Task A, the agent resumed following Task A.
6. 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:

1. 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
2. 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

• #27894: previously handled instructions becoming actionable again after compaction.
• #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.

No implementation files or tests are named. Start by tracing send_message_to_thread delivery through automatic compaction and replacement history, then compare it with the desktop/app-server first-class user-message workaround. Done means the latest delegated instruction, current-turn results, remaining work, and constraints survive compaction without reviving completed instructions or producing an inaccurate report.