On August 18, Codex commit #39266 changed a stored parent grant so it no longer makes a later request beneath an explicitly denied child path look preapproved. That is the practical test of an approval with a memory: it can remember that a person allowed an agent to write in a workspace, but it also has to remember the exception inside that workspace. The detail sounds fussy until the child is a secrets directory and the later request is a read or write arriving through a different tool.
The patch changes the test for remembered authority. Instead of comparing profiles after an intersection that can erase the shape of a denial, it materializes the profiles, declines preapproval when they differ, and runs an accepted replay with the stored grant itself. Its regression suite tries read and write access to secrets/token.txt under a wider workspace-write grant and expects neither to be silently covered. The same coverage reaches exec_command, shell_command, and apply_patch. A remembered “yes” is being treated as a specific object, not a mood.
The executable belongs in the question
Another current Codex commit makes the same point from the other direction. An unfamiliar shell executable can ignore the arguments that make its inner command appear harmless. The new policy therefore evaluates that executable alongside the parsed command, rather than allowing a trusted-looking inner command to lend the executable its reputation. It also puts the executable in the reusable approval key. The tests cover spoofed shell paths and make sure an approval for one custom shell does not bless another.
This is not an argument that every shell should prompt forever. The source preserves configured and recognized system shells, and it keeps inner command restrictions meaningful. It is an argument that a control can only be reused when the thing being trusted has stayed the same.
Measure the uncertainty; do not call it a decision
The third piece is deliberately less dramatic. Guardian v2 now records the gap between the newest tool call and the cached score used by its approval-review contributor. When the lag crosses its configured limit, the code records a score_lag fallback counter; focused tests assert both current and stale samples. That is evidence that the review path can expose its own staleness. It is not evidence that a live approval was allowed, denied, escalated, or made safer.
For builders, the next audit is concrete: can a reused grant preserve its narrowest exception, and do approval cache keys include the executable or identity that actually runs the action? For Codex users, the next public signal is a release receipt and a scoped explanation of stale-score handling in a user-visible approval path. Until then, these are main-branch protections and measurements—not a blanket promise about installed software.