Approval rejection follow-up text is delayed, so model continues without immediate user steer

What version of Codex is running?

Observed on current 0.118.0-alpha app-server builds (via Cursor Codex integration).

What issue are you seeing?

When an approval request is rejected with user follow-up text/suggestion, the model often only sees the rejection outcome immediately, while the user’s follow-up instruction arrives later as a separate steer/new-turn input.

During that gap, the model can continue generating alternative attempts that ignore the user’s newly provided direction (because it has not received it yet).

This report is about rejection+suggestion ordering/timing.

Repro

1. Start a turn that triggers an approval prompt (escalated tool call).
2. Reject approval and provide a suggestion/instruction in the same UX flow (e.g. “do X instead”).
3. Observe transport/order:

• rejection/decline is handled immediately
• user suggestion/steer is delivered later as a separate input

1. Model may continue with fallback attempts before that suggestion is visible to it.

Expected behavior

If user rejects and provides replacement guidance in the same action, that guidance should be made available to the model at the earliest safe boundary (ideally same-turn continuation boundary), minimizing the window where it continues without the user’s updated intent.

Actual behavior

There is a delay/ordering gap where only rejection is visible first; user replacement guidance arrives later.

Why this matters

• Wastes tokens on now-unwanted fallback attempts
• Feels like the model is ignoring explicit user direction
• Creates UX confusion around rejection + suggestion flows

Why this is not a duplicate of the related issues

Shared distinction: this issue requires the approval prompt path (reject + suggestion handoff). The related issues below do not require approval flow and focus on queue/interrupt/stuck behavior.

• #13892: TUI queued-follow-up / pending steer state leakage and delayed queued execution.
• #11047: ESC interruption/steering responsiveness while streaming.
• #15842: send-during-output path can get stuck in pending state.

Those can look similar at the surface, but this issue’s trigger and fix surface are the reject+suggestion ordering boundary.

Current mitigation being tested in a fork

A mitigation being tested app-server side is:

1. After rejection, temporarily block new tool calls to prevent blind fallback attempts.
2. On steer arrival, immediately clear the blocked state.
3. Force the in-flight sampling loop to restart at the next safe boundary so prompt/tools are rebuilt with the newly arrived steer.

Why this should help:

• It shrinks/removes the window where the model continues without the user’s replacement guidance.
• It reduces wasted fallback token generation after a rejection.
• It makes reject+suggest behavior deterministic from the model’s perspective.

I can follow up with implementation details after the patch is cleaned/squashed.