[Windows][Desktop Stable + Beta] Resumed task follow-ups become stale or unreadable after restart

What version of the Codex App are you using?

• Stable: OpenAI.Codex 26.820.7780.0
• Beta: OpenAI.CodexBeta 26.727.4816.0
• CLI: codex-cli 0.149.1

What subscription do you have?

ChatGPT Pro ($200/month)

What platform is your computer?

Windows 11 ARM64

What issue are you seeing?

Existing local Codex tasks become unreliable for programmatic follow-up after closing and reopening the desktop app.

The failure is not simple transcript deletion. The task remains listed, the follow-up send call returns success, the UI/task metadata may update, and the durable transcript remains present. However, native task history/event APIs can return stale or empty data until another app restart.

Observed in Stable:

1. A pre-restart task received a new follow-up after the app reopened.
2. The follow-up executed and was visible/persisted.
3. The native wait API returned latestAssistantMessage=null.
4. The native read API returned the newest turn with no items.
5. After restarting the app again, the same completed turn was reconstructed and readable.

Observed in Beta with three inert continuity-canary tasks:

1. After reopening Beta, all three prior stage-3 replies were retrievable.
2. Full history reads failed consistently with:

``
paginated threads do not support thread/read(includeTurns=true)
``

1. New post-restart follow-ups were sent to all three tasks; each send returned success.
2. One task produced a normally completed response retrievable through the wait API.
3. The other two tasks updated their timestamps/unread state, but the wait API remained stuck on their prior turns and did not expose the new turns.
4. Those prior turns contained final answers but were internally labeled interrupted, with error=null and no completion timestamp.

Earlier in the same incident, another stored task could not resume with:

failed to deserialize stored thread item ...: invalid type: sequence, expected a string

This made persistent controller/worker/reviewer task orchestration unsafe: a send can appear accepted while the coordinating task cannot reliably observe the resulting turn.

What steps can reproduce the bug?

1. Create at least three local project tasks.
2. Send an inert prompt to each and wait for a unique exact final response.
3. Fully close and reopen Codex Desktop.
4. Verify the existing responses are present.
5. Send one new inert follow-up to each existing pre-restart task.
6. Use native task wait/read controls to retrieve the new turns.
7. Observe that some sends complete normally while others remain absent or stale in wait/read despite task metadata changing.
8. Restart Codex again and retry the native reads; previously missing completed turns may then appear.

The problem reproduced across both Stable and Beta installations, although the exact failure presentation differed.

What is the expected behavior?

• Existing tasks should resume consistently after a normal app restart.
• A successful follow-up send should be observable through native wait/read controls without another restart.
• Full paginated history reads should return ordered turns rather than a compatibility error.
• A turn with a final answer and no error should not remain labeled interrupted.
• Durable transcript projection and live task-event state should converge automatically and atomically.

Additional information

Read-only inspection found the durable JSONL transcripts and local SQLite history intact and ordered for the tested turns. No SQLite database or transcript was modified. This appears to be a resumed-task live projection/event visibility defect rather than actual transcript loss or database corruption.

No task IDs, repository names, filesystem paths, prompts, source code, credentials, raw logs, or private transcript content are included in this public report.

Potentially related: #40342, which reports a different paginated-history projection failure where durable rollout content exists but the projected history is incomplete.