mirror of https://github.com/openai/codex.git synced 2026-09-05 15:18:41 +00:00

Files

Owen Lin 23aac925e7 feat(core): emit canonical review mode items (#31473 )

## Description

This PR moves review-mode markers onto canonical `TurnItem` lifecycle:

- `TurnItem::EnteredReviewMode`
- `TurnItem::ExitedReviewMode`

Core now emits `ItemStarted` / `ItemCompleted` for both. The completed
items map back into the existing `EnteredReviewMode` /
`ExitedReviewMode` events, so raw core event consumers and legacy
rollout persistence keep seeing the old events.

This is the compatibility layer needed before paginated rollouts persist
review markers as `ItemCompleted(TurnItem)`.

## Why

Review markers were one of the remaining app-server thread items created
directly from legacy events. Giving them canonical items lets paginated
history persist stable turn/item IDs without changing legacy rollouts.

## What changed

- Added canonical review-mode `TurnItem`s and switched review flow to
emit their lifecycle.
- Added completed-item → legacy review event mappings with stable
turn/item IDs.
- Switched app-server live notifications to the generic canonical item
path and kept legacy replay compatible with old payloads.
- Updated `ThreadHistoryBuilder` to replay canonical review items even
though review turns still do not emit `TurnStarted`.

2026-07-08 09:59:50 -07:00

src

feat(core): emit canonical review mode items (#31473 )

2026-07-08 09:59:50 -07:00

BUILD.bazel

build: run buildifier from just fmt (#28125 )

2026-06-13 21:43:39 -07:00

Cargo.toml

core: support extension-owned turn items (#31283 )

2026-07-08 03:55:13 +00:00

README.md

fix: separate codex mcp into codex mcp-server and codex app-server (#4471 )

2025-09-30 07:06:18 +00:00

README.md

codex-protocol

This crate defines the "types" for the protocol used by Codex CLI, which includes both "internal types" for communication between codex-core and codex-tui, as well as "external types" used with codex app-server.

This crate should have minimal dependencies.

Ideally, we should avoid "material business logic" in this crate, as we can always introduce Ext-style traits to add functionality to types in other crates.