title: 'Codex follow-up request is accepted in one turn but tool work is emitted in an unaccepted successor turn'
severity: 'major'
target: 'get-bb/bb'
Summary
On a fresh Codex-provider thread, a later turn/start request can be persisted as accepted and completed in turn A, while the provider's actual reasoning/tool call is emitted in a newly started turn B that has no turn/input/accepted event. Any consumer that correctly binds effects to the accepted turn must reject the otherwise-valid tool call.
Reproduction
- Start a fresh Codex thread with a registered native BB agent tool.
- Complete one ordinary tool-calling turn successfully.
- Send a second
turn/start request that explicitly calls the same tool.
- Inspect the append-only thread events.
Observed
client/turn/requested for request R targets a new turn.- turn A starts and records
turn/input/accepted for R.
- turn A immediately records
turn/completed with no work items.
- turn B starts at the same timestamp without
turn/input/accepted.
- the requested tool call starts/completes in turn B.
This reproduced on multiple fresh threads. The first tool-calling turn did not split.
Expected
The provider work caused by request R must remain in the turn that records R's input acceptance, or the successor turn must carry an explicit durable correlation to R that effect consumers can validate. A completed/unaccepted successor must not inherit the request implicitly.
Safety impact
This is not a presentation-only mismatch. Exactly-bound tool consumers must fail closed, so valid user-requested tool work becomes unusable. Weakening consumers to accept a tool call from an unrelated/unaccepted turn would create a cross-turn authority bug.
Notes
No private plugin, policy, repository, thread identifier, nonce, or product-specific workflow is required to reproduce this event-order defect.
title: 'Codex follow-up request is accepted in one turn but tool work is emitted in an unaccepted successor turn'
severity: 'major'
target: 'get-bb/bb'
Summary
On a fresh Codex-provider thread, a later
turn/startrequest can be persisted as accepted and completed in turn A, while the provider's actual reasoning/tool call is emitted in a newly started turn B that has noturn/input/acceptedevent. Any consumer that correctly binds effects to the accepted turn must reject the otherwise-valid tool call.Reproduction
turn/startrequest that explicitly calls the same tool.Observed
client/turn/requestedfor request R targets a new turn.turn/input/acceptedfor R.turn/completedwith no work items.turn/input/accepted.This reproduced on multiple fresh threads. The first tool-calling turn did not split.
Expected
The provider work caused by request R must remain in the turn that records R's input acceptance, or the successor turn must carry an explicit durable correlation to R that effect consumers can validate. A completed/unaccepted successor must not inherit the request implicitly.
Safety impact
This is not a presentation-only mismatch. Exactly-bound tool consumers must fail closed, so valid user-requested tool work becomes unusable. Weakening consumers to accept a tool call from an unrelated/unaccepted turn would create a cross-turn authority bug.
Notes
No private plugin, policy, repository, thread identifier, nonce, or product-specific workflow is required to reproduce this event-order defect.