Windows PowerShell false positive: Downloads lookup plus an unused URL is rejected

What version of the Codex App are you using (From “About Codex” dialog)?

26.901.5280.0 (Windows desktop app); active bundled command runner: codex-cli 0.153.4

What subscription do you have?

Not included in this report; the observed failure is a local pre-execution command-policy rejection.

What platform is your computer?

x64 Windows; PowerShell 7.5.3; effective execution policy RemoteSigned; language mode FullLanguage. Observed September 8, 2026.

What issue are you seeing?

Codex rejects a harmless PowerShell command that combines a Windows Downloads-folder lookup through Shell.Application with an unused HTTPS URL string. The command neither opens the URL nor downloads or launches anything. The same folder lookup succeeds when submitted without the URL string.

The tool rejects the command before execution with a CreateProcess rejection ending in:

rejected: blocked by policy

The original encounter was an authorized installer download, where the folder lookup and the download URL appeared in one script. The reproduction below removes the download entirely and retains the same rejection.

What steps can reproduce the bug?

Submit this as a PowerShell command through Codex's command-execution tool:

$diagnosticDownloadsFolder = (New-Object -ComObject Shell.Application).Namespace('shell:Downloads').Self.Path
$diagnosticReference = 'https://example.com'
$diagnosticDownloadsFolder
$diagnosticReference

The URL is only assigned and printed. No network request or application launch occurs. The command is rejected before execution.

What is the expected behavior?

The command should print the Downloads folder location and a URL string. It performs no network request or application launch.

Please narrow detection to actual URL-bearing launch operations while preserving the intended protection. A read-only known-folder lookup plus an unrelated URL string should not be classified as a URL launch. A rejection that identifies the triggering rule would also make diagnosis clearer.

Additional information

Diagnostic results

Matching source condition

The public implementation of is_dangerous_powershell_words treats a command as dangerous when its token list contains both a URL and a token containing shellexecute or shell.application. It does not establish whether that URL is passed to a launch operation.

Source inspected: https://github.com/openai/codex/blob/main/codex-rs/shell-command/src/command_safety/windows_dangerous_commands.rs#L52-L58

The matching source path and relevant string literals were also found in the installed command-runner binary. The public source was inspected on the default branch; its exact commit was not matched to the installed build.

Related reports

• #40060 reports the related Start-Process plus unrelated-URL branch.
• #43633 discusses UseShellExecute=false being matched by the same substring heuristic.

This report supplies a distinct read-only Shell.Application known-folder reproduction with no launch operation and no network request at all.

This report intentionally excludes private folder locations and raw application logs.

Start in codex-rs/shell-command/src/command_safety/windows_dangerous_commands.rs around lines 52-58 and reproduce the supplied PowerShell command through the command-execution tool. Compare the Downloads lookup plus unused URL with the lookup alone and the related Start-Process report #40060. Done means the read-only lookup with an unrelated URL is not rejected while the intended URL-launch protection remains intact.