Long-lived session silently retains stale auto_review.policy after config repair

Summary

A long-lived Codex session continued using an older automatic-approval policy after ~/.codex/config.toml was repaired on disk. The UI exposed neither the policy snapshot in force nor a supported reload transition. A routine provider operation was therefore rejected for payload-specific consent after the persisted policy had explicitly authorized that operation class.

Observed chronology

• The session was already running.
• At 2026-08-26 14:52:34 +0300, ~/.codex/config.toml was updated with [auto_review].policy broadly authorizing ordinary selected AI-provider work over in-scope private project material, while retaining explicit credential, unrelated-data, destructive, publication, deployment, messaging, new-destination, confidentiality, and scope-expansion boundaries.
• At 14:54–14:55, the originating project committed and closed its remediation after a successful acceptance run from a policy-aware session.
• Later, this older session submitted a reviewed Ferret-to-Codex invocation over task-declared sibling-project corpus. Auto-review rejected it as unacceptable private-data egress and required exact-payload authorization.
• No provider process started.

The refusal is consistent with the session retaining its pre-repair policy snapshot. This report does not claim that a freshly loaded reviewer ignored the repaired policy.

Impact

Long-lived sessions can continue to obstruct ordinary work after approval governance is repaired, while presenting no visible indication that their reviewer is stale. Retrying is undesirable; users need to know that a fresh session is required, or be able to reload safely.

Requested repair

Please provide one or more of:

1. supported hot reload of auto_review.policy and relevant approval configuration;
2. an explicit command/UI action that restarts or reloads the approval reviewer without losing task custody;
3. visible approval-policy provenance (loaded path, digest/version, load timestamp) in session diagnostics and approval decisions;
4. a warning when on-disk approval configuration changes after the session snapshot was loaded.

A regression should start a session with policy A, change the persisted config to policy B, then prove either that the reviewer reloads B or that the session clearly reports B is not active and gives a supported transition. It should not silently continue deciding under A.

Privacy

No corpus contents, credentials, provider outputs, or account identifiers are included in this report.

Start with the long-lived session's approval reviewer and its loading of ~/.codex/config.toml; reproduce the reported sequence with policy A, then change the persisted configuration to policy B. Done means the reviewer safely reloads B or clearly reports that A remains active and provides a supported transition, with provenance or a change warning as appropriate.