What version of Codex CLI is running?
Observed on current main as of commit 3af6b0dff5a45f31dc802c22f1ad0c94e32352b8 in my fork:
happyme531@3af6b0d
What issue are you seeing?
When a turn produces multiple approval requests that are equivalent for session-approval purposes, choosing Approve for this session on the first one does not immediately release the rest of the already-pending matching approvals in the same turn.
Instead, the user still has to confirm the remaining queued approvals one by one, even though the session approval cache has already been updated and later requests would be auto-approved.
From the user perspective this feels like bulk/session approval only starts working on the next round, rather than applying to the current batch of pending approvals.
What steps can reproduce the bug?
- Start a turn that emits multiple matching command or patch approval requests in the same turn.
- Approve the first request with Approve for this session.
- Observe that the remaining already-pending matching approvals are still shown and still require explicit confirmation.
What is the expected behavior?
Once the first matching request is approved for the session, any already-pending approvals in the same turn that are fully covered by that same session approval cache entry should be auto-resolved immediately, without requiring additional manual clicks.
Additional information
From local code inspection on main, the behavior appears to come from the combination of:
with_cached_approval() only checking the cache before issuing each requestpending_approvals being tracked per approval idnotify_approval() resolving only the single addressed pending approval- the TUI approval overlay processing requests as a queue of individual prompts
So once several approvals are already pending, updating the session cache on the first ApprovedForSession does not cause the other already-pending matching approvals to be re-evaluated or auto-resolved.
I validated a fix in my fork that stores approval-cache keys alongside pending approvals and, on ApprovedForSession, auto-resolves same-turn pending approvals whose cache keys are now fully covered by the session cache.
That fix also includes a targeted regression test:
approved_for_session_auto_resolves_matching_pending_approvals_in_same_turn
If useful, I can open a PR against this issue with the tested patch from the commit linked above.
What version of Codex CLI is running?
Observed on current
mainas of commit3af6b0dff5a45f31dc802c22f1ad0c94e32352b8in my fork:happyme531@3af6b0d
What issue are you seeing?
When a turn produces multiple approval requests that are equivalent for session-approval purposes, choosing Approve for this session on the first one does not immediately release the rest of the already-pending matching approvals in the same turn.
Instead, the user still has to confirm the remaining queued approvals one by one, even though the session approval cache has already been updated and later requests would be auto-approved.
From the user perspective this feels like bulk/session approval only starts working on the next round, rather than applying to the current batch of pending approvals.
What steps can reproduce the bug?
What is the expected behavior?
Once the first matching request is approved for the session, any already-pending approvals in the same turn that are fully covered by that same session approval cache entry should be auto-resolved immediately, without requiring additional manual clicks.
Additional information
From local code inspection on
main, the behavior appears to come from the combination of:with_cached_approval()only checking the cache before issuing each requestpending_approvalsbeing tracked per approval idnotify_approval()resolving only the single addressed pending approvalSo once several approvals are already pending, updating the session cache on the first
ApprovedForSessiondoes not cause the other already-pending matching approvals to be re-evaluated or auto-resolved.I validated a fix in my fork that stores approval-cache keys alongside pending approvals and, on
ApprovedForSession, auto-resolves same-turn pending approvals whose cache keys are now fully covered by the session cache.That fix also includes a targeted regression test:
approved_for_session_auto_resolves_matching_pending_approvals_in_same_turnIf useful, I can open a PR against this issue with the tested patch from the commit linked above.