fixes https://github.com/openai/codex/issues/10160 and some more.
## Description
Hardens Git command safety to prevent approval bypasses for destructive
or write-capable invocations (branch delete, risky push forms,
output/config-override flags), so these commands no longer auto-run as
“safe.”
- `git branch -d` variants (especially in worktrees / with global
options like -C / -c)
- `git show|diff|log --output` ... style file-write flags
- risky Git config override flags (-c, --config-env) that can trigger
external execution
- dangerous push forms that weren’t fully caught (`--force*`,
`--delete`, `+refspec`, `:refspec`)
- grouped short-flag delete forms (e.g. stacked branch flags containing
`d/D`)
will fast follow with a common git policy to bring windows to parity.
---------
Co-authored-by: Eric Traut <etraut@openai.com>
### What
Implemented detection for dangerous "force delete" commands on Windows
to trigger the user approval prompt when `--ask-for-approval on-request`
is set. This aligns Windows behavior with the existing safety checks for
`rm -rf` on Linux.
### Why
Fixes#8567 - a critical safety gap where destructive Windows commands
could bypass the approval prompt. This prevents accidental data loss by
ensuring the user explicitly confirms operations that would otherwise
suppress the OS's native confirmation prompts.
### How
Updated the Windows command safety module to identify and flag the
following patterns as dangerous:
* **PowerShell**:
* Detects `Remove-Item` (and aliases `rm`, `ri`, `del`, `erase`, `rd`,
`rmdir`) when used with the `-Force` flag.
* Uses token-based analysis to robustly detect these patterns even
inside script blocks (`{...}`), sub-expression `(...)`, or
semicolon-chained sequences.
* **CMD**:
* Detects `del /f` (force delete files).
* Detects `rd /s /q` (recursive delete quiet).
* **Command Chaining**: Added support for analyzing chained commands
(using `&`, `&&`, `|`, `||`) to separate and check individual commands
(e.g., catching `del /f` hidden in `echo log & del /f data`).
### Testing
Added comprehensive unit tests covering:
* **PowerShell**: `Remove-Item -Path 'test' -Recurse -Force` (Exact
reproduction case).
* **Complex Syntax**: Verified detection inside blocks (e.g., `if
($true) { rm -Force }`) and with trailing punctuation.
* **CMD**:
* `del /f` (Flagged).
* `rd /s /q` (Flagged).
* Chained commands: `echo hi & del /f file` (Flagged).
* **False Positives**:
* `rd /s` (Not flagged - relies on native prompt).
* Standard deletions without force flags.
Verified with `cargo test` and `cargo clippy`.
---------
Co-authored-by: Eric Traut <etraut@openai.com>
## Description
Introduced `ExternalSandbox` policy to cover use case when sandbox
defined by outside environment, effectively it translates to
`SandboxMode#DangerFullAccess` for file system (since sandbox configured
on container level) and configurable `network_access` (either Restricted
or Enabled by outside environment).
as example you can configure `ExternalSandbox` policy as part of
`sendUserTurn` v1 app_server API:
```
{
"conversationId": <id>,
"cwd": <cwd>,
"approvalPolicy": "never",
"sandboxPolicy": {
"type": ""external-sandbox",
"network_access": "enabled"/"restricted"
},
"model": <model>,
"effort": <effort>,
....
}
```
Previous to this PR, we used a hand-rolled PowerShell parser in
`windows_safe_commands.rs` to take a `&str` of PowerShell script see if
it is equivalent to a list of `execvp(3)` invocations, and if so, we
then test each using `is_safe_powershell_command()` to determine if the
overall command is safe:
6e6338aa87/codex-rs/core/src/command_safety/windows_safe_commands.rs (L89-L98)
Unfortunately, our PowerShell parser did not recognize `@(...)` as a
special construct, so it was treated as an ordinary token. This meant
that the following would erroneously be considered "safe:"
```powershell
ls @(calc.exe)
```
The fix introduced in this PR is to do something comparable what we do
for Bash/Zsh, which is to use a "proper" parser to derive the list of
`execvp(3)` calls. For Bash/Zsh, we rely on
https://crates.io/crates/tree-sitter-bash, but there does not appear to
be a crate of comparable quality for parsing PowerShell statically
(https://github.com/airbus-cert/tree-sitter-powershell/ is the best
thing I found).
Instead, in this PR, we use a PowerShell script to parse the input
PowerShell program to produce the AST.
This PR threads execpolicy2 into codex-core.
activated via feature flag: exec_policy (on by default)
reads and parses all .codexpolicy files in `codex_home/codex`
refactored tool runtime API to integrate execpolicy logic
---------
Co-authored-by: Michael Bolin <mbolin@openai.com>
Without proper `zsh -lc` parsing, we lose some things like proper
command parsing, turn diff tracking, safe command checks, and other
things we expect from raw or `bash -lc` commands.
Implement command safety for PowerShell commands on Windows
This change adds a new Windows-specific command-safety module under
`codex-rs/core/src/command_safety/windows_safe_commands.rs` to strictly
sanitise PowerShell invocations. Key points:
- Introduce `is_safe_command_windows()` to only allow explicitly
read-only PowerShell calls.
- Parse and split PowerShell invocations (including inline `-Command`
scripts and pipelines).
- Block unsafe switches (`-File`, `-EncodedCommand`, `-ExecutionPolicy`,
unknown flags, call operators, redirections, separators).
- Whitelist only read-only cmdlets (`Get-ChildItem`, `Get-Content`,
`Select-Object`, etc.), safe Git subcommands (`status`, `log`, `show`,
`diff`, `cat-file`), and ripgrep without unsafe options.
- Add comprehensive unit tests covering allowed and rejected command
patterns (nested calls, side effects, chaining, redirections).
This ensures Codex on Windows can safely execute discover-only
PowerShell workflows without risking destructive operations.
Certain shell commands are potentially dangerous, and we want to check
for them.
Unless the user has explicitly approved a command, we will *always* ask
them for approval
when one of these commands is encountered, regardless of whether they
are in a sandbox, or what their approval policy is.
The first (of probably many) such examples is `git reset --hard`. We
will be conservative and check for any `git reset`
refactors command_safety files into its own package, so we can add
platform-specific ones
Also creates a windows-specific of `is_known_safe_command` that just
returns false always, since that is what happens today.
