Compacted or resumed context can repeat completed thread creation when the execution receipt is missing

Summary

Codex Desktop can retain a previous user instruction to create a named thread while losing the execution evidence that the thread was already created. A later request referring to that thread may then be interpreted as a new creation request, producing duplicate same-title threads.

Observed behavior

1. The user asks Codex to create a durable Sol thread named ExampleThread.
2. Codex creates the thread.
3. The conversation is later compacted or resumed from compacted context.
4. The earlier creation request remains visible, but the prior creation receipt or thread ID is unavailable in the reconstructed context.
5. The user says “ask ExampleThread,” referring to the existing thread.
6. Codex creates another ExampleThread instead of locating and using the existing one.
7. The sidebar shows duplicate same-title threads.

The precise internal mechanism is unconfirmed, but this is consistent with compaction preserving user intent while dropping external execution state.

Correlated cross-thread symptom

In the same session, immediately after the thread-creation operation, a separate cross-thread interaction exhibited the behavior described in #40977: the target completed, but the other thread could not see or retrieve its response. This temporal correlation is observed; causation is unconfirmed.

Expected behavior

• Completed external actions should survive compaction with their IDs and receipts.
• If the outcome is unknown, it should be represented as unknown, not implicitly treated as pending.
• Before creating a thread, Codex should reconcile against live thread state.
• If a matching thread exists, Codex should use it.
• If multiple matches exist, Codex should inspect them or ask the user.
• A failed or missing create_thread receipt should not be retried blindly.
• Thread creation should support an idempotency key or equivalent find-or-create behavior.

Broader impact

This report demonstrates the problem with thread creation. The suspected underlying failure mode—compacted context preserving user intent while losing tool execution state—could plausibly affect other side-effecting operations that share the same orchestration or retry path. That broader impact is a hypothesis requiring investigation, not an observed result in this report.

The failure may share a root cause with #42695, where compaction during a send_message_to_thread-triggered turn caused an obsolete instruction to regain authority and produced an inaccurate execution report. The trigger and user-visible symptom differ, so this report does not assert that they are duplicates.

Related issues

• #36592 — create_thread reports failure after creating the task, causing duplicates
• #34076 — recovery creates a duplicate instead of reattaching an existing thread
• #31822 — compaction loses prior task context
• #40977 — read_thread omits completed response after context compaction
• #42695 — compaction can revive an obsolete instruction during cross-thread delivery

Environment

• Codex Desktop: [version]
• OS: [OS/version]
• Model: [model]
• Thread ID: [thread ID, if available]

No files or tests are identified. Start by tracing compaction and context reconstruction around the create_thread, read_thread, and send_message_to_thread entry points, then inspect how execution receipts and thread IDs are represented. Done means an existing matching thread is reused after compaction, unknown outcomes are not blindly retried, and regression coverage verifies the behavior.