Add scoped owner authorization and false-positive recovery for sensitive operations

What variant of Codex are you using?

Codex CLI 0.144.5 on Linux 6.8.0-134-generic x86_64.

What feature would you like to see?

Please add an auditable, one-time, scope-limited authorization mechanism for legitimate sensitive-data operations and for recovering from overbroad hook denials.

A customer explicitly supplied registrar access information to a service provider for a named DNS task. The workspace owner then explicitly delegated that exact operation to Codex. The workflow was still blocked because the information had appeared in a private conversation. There was no supported path to authorize ephemeral use for the named service and action, even though the task was reversible and the owner accepted the risk.

The desired flow is:

1. Codex shows the exact service, identity, action, and requested duration/scope.
2. The owner grants a one-time authorization that cannot be reused for another service or action.
3. Codex may enter the value ephemerally but must not log, persist, export, echo, or store it.
4. Irreversible or materially risky steps require a separate confirmation.
5. The audit record stores only a secret reference, scope, result, and timestamps.

This would preserve strong defaults without turning every accidental or owner-approved plaintext appearance into a permanent operational dead end.

Additional information

This environment also uses owner-installed PreToolUse hooks. I understand that custom hook policy is not maintained by OpenAI, but Codex currently provides weak diagnostics and no reliable recovery path when those hooks overmatch.

Two concrete false-positive patterns occurred in the same session:

• A safe prompt asking the owner to choose an access method and a customer-facing password-rotation advisory were blocked by authentication keyword matching.
• The UI repeatedly emitted browser process admission ceiling reached while the authoritative lifecycle status reported 137 browser-family processes, a 320-process admission threshold, and circuit: closed. A subsequent harness command was blocked as lease state is corrupt, while the immediately repeated status still reported leaseStateCorrupt: false.

Requested hook-platform improvements:

• Include hook identity, rule version, measured inputs, and a stable denial ID in every denial.
• Let an administrator distinguish an advisory from a mandatory block.
• Provide an auditable administrator recovery or appeal token scoped to one command category.
• Prevent stale or contradictory hook telemetry from being surfaced as a current hard stop.
• Provide a first-class “Report false positive” action from a denied Codex tool call.

No credentials, account identifiers, customer personal data, domains, OTPs, certificates, or private conversation content are included in this report.