[macOS app] Multi-agent Goal history desync after restart causes thread_not_found

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

26.831.20005 (build 7524); bundled codex-cli 0.152.0

What subscription do you have?

ChatGPT Pro on the reporting account; also reproduced under two additional ChatGPT accounts

What platform is your computer?

Darwin 25.6.0 arm64 arm (macOS 26.6.2 build 25G83)

What issue are you seeing?

The macOS ChatGPT/Codex desktop app can enter a split state after its app-server restarts during a long-running multi-agent Goal task.

The durable rollout remains intact and readable, but the local history projection stops advancing. The UI still treats an old turn as active. Attempts to continue or stop then fail with JSON-RPC -32600 thread_not_found and show:

• Error creating chat: thread not found
• Failed to stop chat

This occurred across a cluster of three large Goal tasks. They created 95 subagent threads total (35, 30, and 30), including nested agents at depths 2 and 3.

The three parent transcript counters recorded 522,633,166 raw tokens, including 512,764,800 cached-input tokens. I understand these raw counters are not equivalent to billed or rate-limit usage. I am including them to show the scale of repeated processing before the tasks became stuck.

What steps can reproduce the bug?

I have not deliberately repeated this reproduction because it consumes substantial subscription allowance.

Observed sequence:

1. Start a large local task in Goal mode at Ultra reasoning with applicable prompt/project instructions permitting delegation.
2. The parent launches multiple waves of subagents. Some subagents launch descendants.
3. The desktop app/app-server restarts or updates while the Goal is active.
4. The task is resumed after the restart.
5. Later, attempt to steer/continue or stop the parent task.
6. The UI reports thread not found or Failed to stop chat even though the rollout still exists.

Most clearly affected parent: 01a06461...44626. The full ID is being provided privately through in-app feedback.

At 2026-09-03 15:33:36 and 15:33:53 EDT:

• UI sent turn/steer
• app-server returned JSON-RPC -32600
• failure reason was thread_not_found

At 2026-09-03 15:45:23 EDT:

• thread/goal/set succeeded
• the immediately following turn/interrupt failed with thread_not_found

Local diagnostic evidence for that task:

• Rollout exists, validates, and is 25,448,509 bytes
• History projection stopped at byte 194,230
• Rollout contains a duplicated ordinal 28 around the restart/resume boundary
• Runtime-facing task status is notLoaded
• Rollout and token counter stopped advancing at 2026-09-03 13:22:07 EDT

The two other task trees produced related stale-turn behavior, including active_turn_mismatch. Some of those requests succeeded only after an automatic retry.

What is the expected behavior?

After an app/app-server restart, a task with an intact rollout should reload successfully and its history projection should recover or rebuild.

The UI should use the actual active turn ID. Stop should either interrupt the current turn or report that the task is already stopped. It should not target an unloaded thread, retain a stale active-turn ID, or leave the task unusable.

Once the user stops or pauses the task, further agent work and subscription usage should cease immediately.

Additional information

Additional environment details:

• Bundled Codex CLI: 0.152.0
• macOS build: 25G83
• Architecture: Apple Silicon / arm64
• Model: gpt-5.6-sol
• Reasoning effort: Ultra
• No explicit subagent concurrency cap was configured

A version transition occurred during the affected Goal's first turn:

• Release 26.825.51511 stopped at approximately 2026-09-02 19:08:55 EDT
• Release 26.831.20005 launched at approximately 19:09:00 EDT
• thread/resume succeeded at approximately 19:10:20 EDT
• The duplicated ordinal followed this restart/resume boundary

Retained desktop logs show 11 thread_not_found failures on turn/steer across four tasks since August 31, spanning app releases 26.825.41651 and 26.831.20005.

Related issues reviewed: #33046, #42099, #32728, and #38451. This report differs from the no-rollout cases because this task has a durable, readable rollout while its history projection is stale.

I stopped the two healthy parent tasks and paused the affected Goal. I preserved the local session and database files. I have not deleted caches, transcripts, or databases. Sanitized log excerpts and full task IDs can be provided privately.

Start with the app-server restart and resume flow, especially the thread/resume, turn/steer, turn/interrupt, and thread/goal/set entry points described in the report. Trace how an intact rollout updates the history projection and active turn after restart; done means the projection recovers, requests target the actual turn, and stopping no longer returns thread_not_found.