Failed to fork current session through the app server

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #40109
• #40178

Powered by Codex Action

This has the same root cause as the thread-store half of #40630 — I posted the full analysis there: https://github.com/openai/codex/issues/40630#issuecomment-5413897910

Short version: on resume (and when preparing a fork), the recorder reverse-scans the rollout tail with a typed RolloutLine parse, which under serde_json/arbitrary_precision rejects any record carrying a float — typically the token_count event with used_percent. The SQLite projection had already accepted that record, so the recorder steps back one and re-issues its ordinal, and every later write fails with expected ordinal N, got N-1. No crash needed, which is why you hit it on macOS. Unit test that reproduces it and a two-file fix are linked in that comment.

I can reproduce the same underlying thread/fork failure in the Codex Desktop app on Windows.

Environment

• Codex app package: OpenAI.Codex_26.820.9563.0_x64
• OS: Windows 11 Pro x64, build 26200
• Model shown in the affected tasks: gpt-5.6-sol (max reasoning)

Reproduction and observed result

Using the Desktop UI action to open a side conversation failed for two separate, existing active local conversations. I then reproduced the same failure through the app control plane's same-directory fork operation.

Both failures return code -32603 and the same chain:

failed to prepare paginated fork:
thread-store internal error:
thread history projection expected ordinal <N>, got <N-1>

The two observed ordinal pairs were:

• expected 1243, got 1242
• expected 418, got 417

The main conversations remain readable and continue to run; only the side-conversation / thread/fork operation fails. This reproduces across two unrelated local projects, so it does not appear to be specific to one project workspace.

Expected behavior

Opening a side conversation should succeed for an otherwise usable conversation, or the product should provide a safe supported recovery that preserves the original conversation.

For privacy, I have not included thread IDs, local project paths, transcript content, or raw logs. They can be supplied privately to OpenAI if needed.