Codex Desktop Windows: unapproved recovery forks one task into multiple active threads

Summary

Codex Desktop for Windows appears to have recursively forked one user task into multiple user-visible threads during context recovery without the user requesting a new conversation. The duplicate threads then ran or appeared to run concurrently and consumed quota.

Environment

• Product: Codex Desktop for Windows
• Session metadata version: 0.145.0-alpha.18
• The user did not request a fork, new conversation, subagent, or background task.

Evidence

For one task titled "VH Award":

1. The original thread called the thread-fork operation at approximately 2026-07-19 13:51 UTC.
2. A same-title child thread was created about six seconds later and recorded the original as its fork source.
3. That child created another recovery thread about one minute later, titled "Create independent result lineart".
4. The Desktop UI showed multiple spinners for the same work.
5. The user observed approximately 15% quota consumed in a short period.
6. Archiving/stopping the child did not immediately synchronize the UI and backend state; a child could still appear active after being archived.

Expected behavior

• Context recovery must not silently create a new user-visible conversation.
• Require explicit user approval before forking, or enforce one non-recursive recovery path.
• Only one task for one user request should consume quota unless the user explicitly authorizes parallel work.
• Stopping or archiving a child should immediately stop its active turn and update the Desktop UI.

Impact

Unexpected parallel execution consumed quota and made the latest task state ambiguous. The user-reported impact was approximately 15% of available quota.

A local instruction-level workaround was added to prevent unapproved fork/create/subagent calls, but the Desktop/app-server behavior itself remains unresolved. Private logs can be supplied to maintainers if needed.