[Bug] Windows Desktop + Remote Control restores an older selected subthread in multi-thread tasks

What version of the Codex App are you using (From “About Codex” dialog)?

Codex Desktop for Windows 26.814.5167.0; bundled codex-cli 0.148.0-alpha.15.

What subscription do you have?

Paid ChatGPT account (exact tier intentionally omitted).

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

In a long-running root task containing several native subagent/child conversations, Codex Desktop can reopen the root with an older child conversation selected instead of the most recently active/current child. The task then appears to have jumped back to a much earlier phase even though the newer child rollout is still complete and valid on disk.

This is not only an old scroll position. In one inspected occurrence, the target child JSONL was structurally valid and ended with task_complete, but the root task entry in .codex-global-state.json had its subagent panel selectedConversationId set to an older sibling child. Updating that pointer to the intended child restored the correct conversation in the UI without editing the rollout.

The problem is intermittent but recurring across long-lived tasks. Android Remote Control and Windows Desktop are both used against the same host. A stale client overwriting the selected-child state is a suspected trigger, not a proven cause.

What steps can reproduce the bug?

A deterministic reproducer is not established yet. The observed sequence is:

1. Use a long-running root task that has multiple native subagent/child conversations.
2. Open and steer the task from ChatGPT Android Remote Control.
3. Later open the same root task in Codex Desktop on Windows.
4. Intermittently, observe that the subagent panel selects an older child and the transcript appears to have reverted by several turns or to an earlier phase.
5. Inspect the persisted state with private identifiers and content redacted:

• the newer child rollout remains intact and complete;
• the root task's selectedConversationId points to an older sibling child;
• selecting/restoring the intended child makes the newer conversation visible again.

The user did not intentionally switch to the older child, fork the task, or roll back the conversation.

What is the expected behavior?

All connected clients should converge on the authoritative current/last-selected child conversation. Opening a stale Desktop or Remote client must not overwrite a newer selected-child pointer. If selection state conflicts, the UI should prefer the latest versioned update or ask the user, rather than silently displaying an older child as current.

Additional information

This occurrence was diagnosed from local persisted state on 2026-08-19. Full task IDs, child IDs, paths, prompts, project names, and transcript contents are intentionally omitted. Sanitized structural evidence can be provided privately if maintainers request it.

Related reports:

• #35431 covers reopening a long Windows thread at an old message, but remains within the same thread/viewport.
• #30245 covers stale catalog state and turns appended to a wrong existing thread.
• #34767 covers simultaneous active turns through Remote Control.

This report is distinct because the inspected rollout was intact and the wrong state was the persisted selected child within a multi-thread task.