Approval prompt hides intent behind opaque PowerShell path

Codex Approval Prompt Security / UX Bug

Title

Approval UI leads with opaque PowerShell executable paths, hiding intent and encouraging unsafe broad approvals

Summary

Codex Desktop permission prompts on Windows currently surface the shell entrypoint first, for example a command beginning with C:\Windows\System32\WindowsPowerShell\..., while the meaningful action and risk are not visible or legible enough in the approval surface.

This makes the approval decision effectively impossible for a security-aware user. A broad approval scoped to PowerShell is not meaningful consent; PowerShell can run arbitrary code, modify files, launch apps, change configuration, access network resources, and orchestrate COM automation. Technical users are specifically trained not to approve opaque PowerShell commands.

Why This Is A Real Security / Trust Problem

The current prompt appears to ask the user to approve a shell implementation detail rather than the actual action. If the command text after the PowerShell prefix is clipped, hidden, or visually unreadable, the user cannot distinguish between:

• opening PowerPoint in the background to verify a local .pptx;
• running a local audit script against a known workspace file;
• editing Codex config;
• installing a package;
• executing arbitrary file or network operations.

The visible prefix PowerShell communicates almost no useful risk boundary. A remembered approval for a PowerShell prefix is particularly dangerous because it can become an arbitrary-code approval pattern.

Concrete Example

During a deck-generation workflow, Codex needed to run a local PowerPoint COM open-check to verify whether a generated .pptx triggered PowerPoint repair errors. The actual human decision was:

Allow Codex to open PowerPoint locally in the background to verify that this generated deck opens without repair errors. This reads one .pptx file and does not modify it.

But the approval surface exposed the action as a PowerShell command beginning with an opaque Windows PowerShell path. The important user-facing intent was not the primary thing being approved.

Expected Behavior

The approval prompt should lead with a human-readable action summary and risk scope, for example:

Open PowerPoint in the background to verify PreConsensus_Board_Source_Deck_70_v1_artifact.pptx. Scope: launches local PowerPoint through COM automation; reads one file under the trusted workspace; does not modify the deck.

Then show the exact command as secondary / expandable detail.

Recommended Fixes

1. Show a concise intent summary first, not the shell executable.
2. Show target paths and whether the action reads, writes, launches an app, or uses network.
3. Make exact command text visible and copyable, but secondary.
4. Avoid offering persistent approvals for broad shell prefixes such as powershell.exe.
5. Scope remembered approvals to meaningful action categories and target paths, such as:

• python scripts/audit_pptx_layout.py under this workspace;
• presentation cleanup helper under this workspace;
• PowerPoint COM open-check for .pptx files under this workspace.

1. Flag broad shell approvals as high risk.
2. When command text is clipped or hidden, do not allow a remembered approval.

Actual Impact

This bug trains users to approve opaque shell commands because the assistant is being useful. That is the wrong security habit. The more technically competent the user is, the more suspicious the prompt becomes, because they know that approving a PowerShell prefix is not a safe or meaningful grant.

Environment

• Codex Desktop on Windows
• Workspace-trusted project
• Approval prompt for escalated local commands
• Example command class: PowerShell invoking local PowerPoint COM automation for .pptx validation

Requested Priority

This should be treated as a security-adjacent approval-design bug. It is not merely cosmetic. The current UI hides the action that matters and foregrounds an implementation detail that is too broad to approve safely.