Expose explicit rollback boundaries or cursors for app-server rewind

What variant of Codex are you using?

0.130.0

What feature would you like to see?

I am building an internal client directly on top of the app-server API, and I would like to implement rewind/backtrack safely without relying on TUI-internal state.

Today, thread/rollback is difficult to use correctly from a non-TUI client because the public API exposes Thread.turns, while ThreadRollbackParams.num_turns is documented as the number of turns to drop from the end of the thread. That naturally suggests numTurns is measured in the returned app-server Thread.turns.

However, in fact app-server Turns are not always the same unit as core rollback boundaries. A raw Turn may contain multiple user messages, or no user/instruction rollback boundary at all. In those cases, a non-TUI client cannot safely infer the right rollback target from Thread.turns alone unless it also maintains a TUI-like transcript-cell / rollback-boundary model, as discussed in #23000

Feature request: please expose a non-breaking app-server API for safe rewind.

A possible direction would be:

• thread/read includeTurns returns explicit rollback-boundary metadata or cursors;
• rollback can target a boundary / item / cursor directly, instead of an overloaded numeric “turn” count;
• the rollback response returns a transcript projection that is guaranteed to match the surviving core/model history.

The exact design is obviously up to the Codex team. The main ask is that non-TUI app-server clients should be able to implement rewind from the public API alone, without duplicating private TUI transcript-cell logic.

This would also help avoid current and future ambiguity around “turn” semantics.

For example, in multi-steer cases, the built-in TUI live rewind/model history can be correct, while app-server replay / thread/read includeTurns / resume / fork may render the surviving transcript as if more history had been dropped than the rewind actually removed. That is a transcript/replay correctness issue today, and it becomes harder for external app-server clients because they do not have the TUI’s internal cell model.

This may also matter more as Codex grows features such as goals or multi-agent-v2 flows, where raw app-server turns and rollback boundaries may diverge further.

I also noticed that the current Codex App appears to support editing only the last message. A more explicit rollback-boundary / cursor-based API could make richer rewind/edit behavior easier to support consistently across first-party and third-party clients.

Additional information

_No response_