[Bug]: Repeated V2 rollbacks discard retained Codex legacy history or fail in Pi

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

This is on the orchestration V2 branch in #2829, before the fix in #12676.

1. Use Codex CLI 0.155.1 and GPT-6 Astra (gpt-6-astra) with a legacy-history thread in an isolated Git worktree. For a fresh deterministic repro, our test launcher adds the supported historyMode: "legacy" field to thread/start and forwards every other request unchanged to the real CLI.
2. Complete three turns that replace proof.txt with A, then B, then C.
3. Use Edit from here on the C prompt and choose Revert files too. This retains A and B.
4. Use Edit from here on the B prompt and choose Revert files too. This should retain A.
5. Compare T3's retained turns and file contents with the native Codex history (thread/read with includeTurns: true).

Pi reproduction: perform the same rewinds, send a new turn D, then rewind to A again. The final rewind fails.

History-mode scope: default new Codex 0.155.1 sessions use paginated history. Testing that path failed at the first rewind because this V2 adapter does not implement paginated rollback. The repeated-rollback reproduction here explicitly exercises the supported legacy-history path.

Expected behavior

T3 and the provider retain the same conversation. Native Codex turn counts should be 3 → 2 → 1, and proof.txt should be C → B → A. Rewinding again after a new turn should work.

Actual behavior

Codex has 3 → 2 → 0 native turns. T3 still displays completed turn A and restores proof.txt to A, so the provider silently loses context that the UI says it retained.

Pi's final rewind fails with Pi RPC fork failed: Invalid entry ID for forking and leaves the file at D.

The rollback service includes turns from already rolled-back runs in the provider input. Those audit records remain in T3 after the native turns have been removed. A later rewind therefore overcounts turns in Codex or selects a removed fork entry in Pi.

Impact

Major degradation or frequent failure

Repeated rewinds can silently remove retained provider context or fail to restore the requested checkpoint.

Version or commit

Baseline runtime: t3code/codex-turn-mapping at 7ec43faddc (#2829). Fixed runtime: #12676 at 82396a63cf.

Environment

Primary reproduction and updated recording: CachyOS Linux x86_64, Node v26.8.2, Codex CLI 0.155.1 with GPT-6 Astra (gpt-6-astra), legacy history, an isolated development server, and real Git worktrees. Actual native rollout records confirm the model. Additional provider verification: Pi 0.86.0.

Logs or stack traces

Codex CLI 0.155.1 | model: gpt-6-astra | history: legacy
Codex: retained T3 turns = [1]; native provider turns = []; proof.txt = A
Pi: Pi RPC fork failed: Invalid entry ID for forking

Screenshots, recordings, or supporting files

Full-resolution MP4

Proposed fix

#12676 excludes turns belonging to already rolled-back runs. The regression fails before the fix and passes after it. The new Codex 0.155.1 / GPT-6 Astra run retains A/B/C → A/B → A → A/D → A with matching files, unchanged retained turn IDs, and three successful first-attempt rollback receipts. Pi passed the same sequence in its separate verification.

Related reports #6127 (Claude retaining discarded context) and #8958 (unsupported Codex paginated rollback) describe different causes. This reproduction uses Codex history that supports rollback.

Filed and verified with GPT-6 Astra in Codex CLI 0.155.1.

Start in apps/server and reproduce the repeated rollback sequence using the legacy-history Codex setup, then compare T3's retained turns and files with native thread/read output and the Pi fork result. Done means repeated rewinds preserve the provider context and restore the matching file checkpoints; the issue reports that #12676 already provides the fix.