Show a structured risk-and-impact report before native authorization prompts

Feature request

Problem

Codex's native authorization prompt often presents a raw shell command or a broad executable-prefix rule. Many users cannot reliably infer what that command does, its scope, or the consequence of approving it. This creates two unsafe failure modes: blindly approving useful-looking requests, or denying legitimate work because the prompt is opaque.

The issue is broader than command rendering: before the native approval UI appears, the agent should explain the specific operation it is requesting in plain language, so that the user can make an informed decision in the existing authorization prompt.

Proposed behavior

For every approval-gated tool invocation (especially Bash/shell commands, file deletion or overwrite, network/public writes, credential access, privilege escalation, and computer-use actions), Codex should emit a structured pre-approval report in the conversation immediately before requesting native authorization.

The report should use the user's language when possible, state concrete facts from the proposed tool invocation, and preserve the raw command as the source of truth. It must be informational only: it must not auto-approve, weaken sandboxing, or replace the existing approval prompt.

Example:

Warning:
  ╭─ Codex authorization pre-report
  │ Risk: Critical
  │ Tool: Bash
  │ What it will do: Remove the temporary UI data directory, then start an isolated Xvfb session to exercise and screenshot the PinShot application.
  │ Scope: Deletes only `/tmp/lixlin-pin-ui`; writes screenshots under `/tmp`; launches temporary local processes.
  │ Consequences: The specified temporary directory will be removed permanently. The test may create or replace temporary artifacts. It does not target the project source tree.
  │ Why authorization is needed: The command contains recursive deletion and launches local processes outside the sandbox's normal allowance.
  │ Command:
  │   rm -rf /tmp/lixlin-pin-ui && xvfb-run ...
  ╰─ Please decide in the following native Codex authorization prompt.

Requirements / acceptance criteria

• The report appears before the native approval request, in CLI, desktop/app, IDE, and remote surfaces that support conversational output.
• Required fields: risk level, tool, what it will do, affected scope/paths/resources, consequences, and complete command or action details.
• Use a small consistent taxonomy: low, medium, high, critical. Explain the reason for high and critical ratings.
• Detect and call out common irreversible or sensitive effects: deletion, overwrite, reset/force operations, privilege escalation, public/network writes, secret/credential exposure, process termination, and broad persistent authorization scope.
• Clearly distinguish known scope from uncertainty; do not claim that a command is safe merely because it looks familiar.
• The exact command/action remains visible, selectable/copyable, and authoritative; summaries must never silently truncate or rewrite it.
• Persistent/remembered approval options should also display the proposed saved scope and warn when it is broad (for example, approving a shell executable prefix).
• Explanation generation must be robust against prompt injection from command arguments, paths, file contents, or tool output. Such data should be represented as untrusted input, not instructions.
• If Codex cannot produce a meaningful report, it should say so and still show the native prompt; it must not invent safety claims.
• Include an accessibility-friendly text form and localization, including Chinese.

Why an agent-authored report rather than only a UI summary

The agent knows the task-level reason for the action (e.g. “test a temporary graphical session and capture its window”), whereas a command parser alone may only recognize rm -rf and process spawning. The best UX combines deterministic extraction of the command's concrete effects with the agent's task-level explanation, while keeping the native permission mechanism as the final authority.

Related issue

This complements #26933, which correctly identifies that the current approval UI can foreground an opaque shell entrypoint rather than intent. This proposal makes the requirement cross-platform and requires an explicit, auditable report before the native authorization decision.