Windows: PowerShell here-string Python literal data falsely blocked as forced deletion

What version of the Codex App are you using?

Windows desktop; the executable used by the running app-server reports codex-cli 0.154.0-alpha.6.2. The separately installed CLI reports 0.154.0 and was not the affected execution surface.

What platform is your computer?

Windows with PowerShell 7. The active task uses approval policy never with filesystem sandbox disabled/full access. No local exec-policy rule files were loaded. Observed September 13, 2026 UTC.

What issue are you seeing?

Codex's command tool rejects PowerShell here-string data sent to Python as a forced file deletion. The command only prints two literal words. It contains no PowerShell deletion command, Python file operation, network operation, or URL.

What steps can reproduce the bug?

Submit this exact command through the Windows desktop command-execution tool:

@'
print('Remove-Item', '-Force')
'@ | python -

Observed in the installed runtime: immediate pre-process rejection, approximately 0.3 seconds:

exec_command failed: CreateProcess { message: "Rejected(... rejected: blocked by policy)" }

The tool did not create PowerShell or execute Python. A separate direct literal-output control did execute and returned exit code 0:

Write-Output 'Remove-Item example.txt -Force'

That control also only prints text; it requests no deletion. We did not retry a real destructive command or weaken any policy.

What is the expected behavior?

The Python command should print Remove-Item -Force. Here-string contents and external-program data must not be interpreted as PowerShell command invocations. Preserve the intended protection for actual forced deletions.

Additional information

A read-only parse with PowerShell's own AST of the original diagnostic that led to this minimized example found python as its sole command name and no PowerShell command parameters. That diagnostic was searching local logs; no deletion operation was requested.

The behavior is consistent with the public Windows safety heuristic flattening/tokenizing script text and has_force_delete_cmdlet recognizing deletion words and force flags inside rough segments, without preserving here-string/data boundaries:

• Pinned heuristic source
• Pinned decision mapping

This is source correlation, not an assertion that the public commit exactly built the installed executable. The rejection above was observed directly.

Related: #40060 concerns an unrelated URL plus a launch verb. This example contains no URL and no launch verb and exercises the forced-deletion/data boundary instead.

Please provide a parser-aware fix, regression tests covering literal data/here-strings, and a supported fixed release/version. Please expose a stable classifier/reason identifier and triggering span instead of only the generic policy rejection. An allow-all setting or disabled protection is not requested.

Submitted by Codex at the account owner's explicit request. No credentials, private paths, repository content, or raw session logs are included.

Start with codex-rs/shell-command/src/command_safety/windows_dangerous_commands.rs and trace its use through codex-rs/core/src/exec_policy.rs. Reproduce the PowerShell here-string case and add regression coverage for literal data and here-strings. Done means actual forced deletions remain protected while Python data prints successfully, with a stable reason and triggering span exposed.