mirror of
https://github.com/openai/codex.git
synced 2026-04-27 16:15:09 +00:00
bd30bad96f
Guardian events were emitted a bit out of order for CommandExecution
items. This would make it hard for the frontend to render a guardian
auto-review, which has this payload:
```
pub struct ItemGuardianApprovalReviewStartedNotification {
pub thread_id: String,
pub turn_id: String,
pub target_item_id: String,
pub review: GuardianApprovalReview,
// FYI this is no longer a json blob
pub action: Option<JsonValue>,
}
```
There is a `target_item_id` the auto-approval review is referring to,
but the actual item had not been emitted yet.
Before this PR:
- `item/autoApprovalReview/started`
- `item/autoApprovalReview/completed`, and if approved...
- `item/started`
- `item/completed`
After this PR:
- `item/started`
- `item/autoApprovalReview/started`
- `item/autoApprovalReview/completed`
- `item/completed`
This lines up much better with existing patterns (i.e. human review in
`Default mode`, where app-server would send a server request to prompt
for user approval after `item/started`), and makes it easier for clients
to render what guardian is actually reviewing.
We do this following a similar pattern as `FileChange` (aka apply patch)
items, where we create a FileChange item and emit `item/started` if we
see the apply patch approval request, before the actual apply patch call
runs.
11 lines
262 B
Rust
11 lines
262 B
Rust
// Module declarations for the app-server protocol namespace.
|
|
// Exposes protocol pieces used by `lib.rs` via `pub use protocol::common::*;`.
|
|
|
|
pub mod common;
|
|
pub mod item_builders;
|
|
mod mappers;
|
|
mod serde_helpers;
|
|
pub mod thread_history;
|
|
pub mod v1;
|
|
pub mod v2;
|