core-agent-ide/codex-rs/protocol
sayan-oai 5d2702f6b8
fix(tui): conditionally restore status indicator using message phase (#10947)
TLDR: use new message phase field emitted by preamble-supported models
to determine whether an AgentMessage is mid-turn commentary. if so,
restore the status indicator afterwards to indicate the turn has not
completed.

### Problem
`commit_tick` hides the status indicator while streaming assistant text.
For preamble-capable models, that text can be commentary mid-turn, so
hiding was correct during streaming but restore timing mattered:
- restoring too aggressively caused jitter/flashing
- not restoring caused indicator to stay hidden before subsequent work
(tool calls, web search, etc.)

### Fix
- Add optional `phase` to `AgentMessageItem` and propagate it from
`ResponseItem::Message`
- Keep indicator hidden during streamed commit ticks, restore only when:
  - assistant item completes as `phase=commentary`, and
  - stream queues are idle + task is still running.
- Treat `phase=None` as final-answer behavior (no restore) to keep
existing behavior for non-preamble models

### Tests
Add/update tests for:
- no idle-tick restore without commentary completion
- commentary completion restoring status before tool begin
- snapshot coverage for preamble/status behavior

---------

Co-authored-by: Josh McKinney <joshka@openai.com>
2026-02-07 02:39:52 +00:00
..
src fix(tui): conditionally restore status indicator using message phase (#10947) 2026-02-07 02:39:52 +00:00
BUILD.bazel fix(core) Preserve base_instructions in SessionMeta (#9427) 2026-01-19 21:59:36 -08:00
Cargo.toml feat: replace custom mcp-types crate with equivalents from rmcp (#10349) 2026-02-02 17:41:55 -08:00
README.md fix: separate codex mcp into codex mcp-server and codex app-server (#4471) 2025-09-30 07:06:18 +00:00

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.