Emit a lifecycle hook when Double-Esc creates a thread fork

What variant of Codex are you using?

Codex CLI interactive TUI; ideally the shared thread lifecycle used by app-server clients too

What feature would you like to see?

Please emit a first-class lifecycle hook/event when an interactive rewind is committed and creates a forked thread.

Double-Esc lets the user select and edit an earlier prompt. Submitting that prompt forks the conversation, but current hooks do not identify the transition when it occurs. An external coordinator keyed by the Codex session identity cannot atomically release work, locks, or leases owned by the abandoned branch and register the replacement branch. It must infer the fork from private rollout/transcript details or wait for a delayed SessionEnd.

The event should represent the semantic fork, not the raw keypress: Double-Esc can be cancelled, and other CLI/app-server actions may create the same lifecycle transition. A possible contract would:

• fire exactly once after the new thread is durably created and before its first turn/tool hook;
• include the stable root/session ID, source thread ID, new thread ID, fork-point turn or message ID, and a trigger such as tui_rewind;
• expose equivalent identity through command-hook payloads and app-server notifications;
• make later lifecycle events attributable to a concrete thread/generation, so a delayed end from the abandoned branch cannot be mistaken for the current branch.

ThreadForked or SessionFork would both be reasonable names; the exact name and payload should follow the existing lifecycle vocabulary.

Additional information

Example:

1. Configure lifecycle hooks that associate external resources with the current Codex session.
2. Start work, then press Esc twice, choose an earlier prompt, edit it, and submit.
3. Codex continues on a fork. The abandoned branch does not emit an immediate dedicated end/replacement signal, and the new branch emits no dedicated fork event.
4. The integration temporarily sees ambiguous ownership under the same root session and can mis-handle a later end event from the older branch.

Expected: one immediate, unambiguous lifecycle signal for the committed fork, allowing integrations to release the old generation and require the new generation to reacquire its state.

This is narrower than the general hook-parity request in #21753 and complements the existing app-server thread/fork operation: https://developers.openai.com/codex/app-server#start-or-resume-a-thread