Failed to fork current session through the app server #40537

Activity

1. aslldab1

   added

   bugSomething isn't workingSomething isn't working

   on Aug 25, 2026
2. github-actions

   added

   CLIIssues related to the Codex CLIIssues related to the Codex CLI

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   on Aug 25, 2026
3. github-actions commented on Aug 25, 2026

   

   github-actionsbot

   on Aug 25, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Serialize concurrent rollout writers before assigning paginated ordinals #40109
   • [macOS Desktop] Reboot can switch app-server runtime and wedge paginated history at a duplicate ordinal #40178

   Powered by Codex Action
4. Ash20pk commented on Aug 25, 2026

   

   Ash20pk

   on Aug 25, 2026

   More actions

   This has the same root cause as the thread-store half of #40630 — I posted the full analysis there: #40630 (comment)

   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.
5. woshishinidie commented on Aug 27, 2026

   

   woshishinidie

   on Aug 27, 2026 – with ChatGPT Codex Connector

   More actions

   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.
6. sada11232 commented on Sep 4, 2026

   

   sada11232

   on Sep 4, 2026

   More actions

   Additional Windows confirmation: this remains reproducible on app-server 0.153.0, and it can recur after a successful local repair.

   Environment

   • Windows 10 22H2, build 19045
   • ChatGPT/Codex Desktop
   • paginated thread history
   • reproduced with app-server 0.152.1 and 0.153.0

   Sanitized observations

   Every failure returned JSON-RPC code -32603 with:

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

   Observed pairs:

   • expected 775, got 774
   • expected 559, got 554
   • expected 34086, got 34085
   • expected 35022, got 35020

   At each failing checkpoint, thread_history_projection_state.next_rollout_byte_offset pointed to a new-turn boundary (task_started or thread_settings_applied). Immediately before that boundary were one or more event_msg / payload.type=token_count records. The number of adjacent token_count records exactly matched the ordinal delta:

   • 1 record -> delta 1
   • 5 records -> delta 5
   • 2 records -> delta 2

   All relevant SQLite databases passed PRAGMA quick_check.

   For root-cause isolation only (not as a recommended user repair), I first created backups, removed only those non-conversation token_count records from the affected shared-history segment, cleared the derived projection rows, and retried a real Desktop side-chat fork. The fork then succeeded. After the source thread continued and a new history segment was produced, the same failure recurred, first with a delta of 1 and later a delta of 2.

   This is consistent with the typed-decoder / float-bearing token_count mismatch already described above, and shows that the failure is cumulative when multiple adjacent usage-stat records occur at a turn boundary. It also confirms the issue is still present in 0.153.0 rather than being limited to older builds or a one-off corrupted database.

   No thread IDs, transcript text, repository names, local paths, account identifiers, raw logs, or database files are included. I can retain the complete local evidence for a private diagnostic channel if requested by OpenAI.