Spark loses a delegated implementation task after compaction and returns to asking for instructions

Environment

Codex desktop on Windows, PowerShell, model gpt-5.3-codex-spark, reasoning effort high. Exact desktop/build version was not captured. The incident occurred on September 14, 2026 UTC.

Observed behavior

A task initially asked to wait for a panel implementation assignment. Another task then delivered a concrete assignment through send_message_to_thread, including the source checkout and SHA, allowed files, required code/tests, and no-production boundary.

Spark acknowledged that assignment and inspected relevant source files. After a contextCompaction entry, it returned a final answer asking the user to send the tasks, as if only the initial waiting prompt remained. It did not deliver an implementation. The coordinator sent a smaller follow-up restating the assignment and asking it to bound file reads. The same return-to-waiting behavior happened again.

A subsequent follow-up explicitly granted exclusive write access to the isolated checkout. Spark created the requested branch and continued inspecting files, then the task failed with the model's usage-limit message. No implementation diff or test delivery was present in the checkout. The scratch folder contained a copy of the existing module, not an implemented panel.

The usage limit itself is not claimed to be a bug. The issue is loss of continuity of an already-delivered delegated assignment after compaction, followed by repeated reading without delivering the authorized work. Compaction is an observed correlation, not a confirmed root cause.

Observed sequence / reproduction outline

1. Create a task with a short initial message such as “You will receive tasks for a store administration panel.”
2. Deliver the real implementation assignment from another task with send_message_to_thread.
3. Let the receiving task inspect source files until context compaction occurs.
4. Observe it reverting to “Send me the tasks” instead of continuing the assignment.
5. Restate the assignment in a shorter follow-up; in this session the pattern repeated.

One investigation had a very large search result and full-file reads. Those may have contributed to compaction, but they should not cause the active assignment to be lost. The follow-up explicitly requested bounded reads.

Expected behavior

Preserve and continue the delegated assignment across compaction. Implement and test the allowed files, or ask a specific blocking question. Do not fall back to the initial waiting prompt or request an assignment already present in the task.

Privacy and evidence limits

This report intentionally omits private repository contents, commercial data, credentials and full session transcripts. The coordinator verified the task summaries, the compaction marker and clean implementation checkout. It did not reproduce the issue in a new session after the usage limit. No model-wide failure rate or billing defect is asserted.

Related issues #36899 and #38240 were checked; they concern a compact-task quota error or an HTTP compaction failure, rather than a successful compaction followed by loss of the delegated task.

Begin with the provided send_message_to_thread reproduction and inspect task state around the contextCompaction entry; no source files or tests are identified in the report. Done means a delegated assignment survives compaction, the agent either implements and tests the allowed work or asks a specific blocking question, and it does not request the assignment again.