Summary
Switching a live Desktop-owned thread to the Bridge-managed shared app-server left an unfinished turn and produced a duplicate rollout ordinal. After a cold app-server restart, paginated history reconstruction stopped at that boundary: Desktop exposed only the first three turns while the complete JSONL history remained on disk.
Environment
- macOS 27 arm64
- Codex Desktop 26.903.61454
- bundled app-server 0.153.4
- codex-bridge v0.2.8
- affected thread uses
history_mode = paginated
Confirmed evidence
The rollout is valid JSONL and currently contains 19 turn contexts, but has one duplicated ordinal:
2026-09-09T06:20:50.706Z ordinal=146 event_msg token_count
2026-09-09T06:23:58.169Z ordinal=146 event_msg task_started turn=01a084d6-...
The preceding turn 01a084d3-... has tool output and token-count records but no task_complete or turn_aborted. Desktop logged Received turn/started for unknown conversation when the second ordinal 146 was written.
Process evidence from the transition showed a Desktop-private stdio app-server and the new Bridge-managed app-server existing across the handoff. Rollout records do not carry writer PID, so attribution of the first record to the old process is inferred from the process and Desktop-log timeline. The second record is correlated with the managed app-server event received by the relaunched Desktop.
The current shared app-server returns only 3 turns and 37 items for this thread even though new records continue to append to the rollout.
Isolated reproduction of the parser boundary
I copied the rollout into two fresh temporary CODEX_HOME directories and started separate bundled app-server 0.153.4 instances:
- unchanged copy with a fresh state DB: 0 turns, 0 items;
- copy with only the second ordinal 146 and every later ordinal incremented by one: 19 turns, 469 items.
The repaired copy has no duplicate or non-monotonic ordinals. No synthetic terminal event was needed. This isolates the duplicate ordinal as sufficient to break cold history reconstruction.
Expected behavior
- A new app-server must not take writer ownership of a rollout while another app-server has an active turn.
- Resume/takeover should allocate from the physical maximum ordinal in the file, including
token_count and other non-turn records.
- Duplicate or non-monotonic ordinals should produce an explicit repair diagnostic instead of silently returning a valid-looking truncated history.
- Desktop interposition setup should verify that Desktop and its private app-server have exited before starting or exposing the shared writer.
- If takeover finds an unfinished turn from a dead writer, it should preserve the suffix and represent the old turn as interrupted without reusing an ordinal.
Impact
The data is still present and Bridge can display it from raw rollout parsing, but Desktop and native app-server pagination expose only the prefix. Subsequent turns keep appending after the corrupt boundary and remain absent from the rebuilt native history index.
Summary
Switching a live Desktop-owned thread to the Bridge-managed shared app-server left an unfinished turn and produced a duplicate rollout ordinal. After a cold app-server restart, paginated history reconstruction stopped at that boundary: Desktop exposed only the first three turns while the complete JSONL history remained on disk.
Environment
history_mode = paginatedConfirmed evidence
The rollout is valid JSONL and currently contains 19 turn contexts, but has one duplicated ordinal:
The preceding turn
01a084d3-...has tool output and token-count records but notask_completeorturn_aborted. Desktop loggedReceived turn/started for unknown conversationwhen the second ordinal 146 was written.Process evidence from the transition showed a Desktop-private stdio app-server and the new Bridge-managed app-server existing across the handoff. Rollout records do not carry writer PID, so attribution of the first record to the old process is inferred from the process and Desktop-log timeline. The second record is correlated with the managed app-server event received by the relaunched Desktop.
The current shared app-server returns only 3 turns and 37 items for this thread even though new records continue to append to the rollout.
Isolated reproduction of the parser boundary
I copied the rollout into two fresh temporary
CODEX_HOMEdirectories and started separate bundled app-server 0.153.4 instances:The repaired copy has no duplicate or non-monotonic ordinals. No synthetic terminal event was needed. This isolates the duplicate ordinal as sufficient to break cold history reconstruction.
Expected behavior
token_countand other non-turn records.Impact
The data is still present and Bridge can display it from raw rollout parsing, but Desktop and native app-server pagination expose only the prefix. Subsequent turns keep appending after the corrupt boundary and remain absent from the rebuilt native history index.