Support contains/regex rules in execpolicy

Open 💬 3 comments Opened May 27, 2026 by axelcursive

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

It looks like prefix_rule only matches the beginning of the submitted argv. That works for direct commands, but misses cases where the sensitive command is embedded inside a shell string, e.g. bash -c "... some-command ...".

Could execpolicy support a simple contains_rule or regex_rule over the full submitted command/argv?

I know this would not be a perfect security boundary and would not replace sandboxing or runtime interception, but it would catch many practical cases without forcing users to prompt on every bash -c.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#24201

Powered by Codex Action

SylvainWinning · 3 months ago

This seems worth treating as an ergonomics / defense-in-depth feature, but I would keep the rule semantics very explicit so users do not mistake it for shell-aware security parsing.

One possible shape:

keep prefix_rule as the canonical precise argv-prefix matcher;
add a separately named rule such as command_text_rule or argv_contains_rule that matches against a normalized display string or against individual argv tokens;
document that it is advisory and pre-exec only, not a sandbox boundary;
make examples focus on reducing approval noise for common wrapper forms like bash -c, sh -lc, package-manager scripts, or small repo-local wrappers.

Acceptance tests I would expect:

direct some-command still matches the existing prefix rule;
bash -c "some-command --flag" can trigger the contains/regex rule;
benign strings that merely contain the same substring in an unrelated argument are either documented as matches or covered by a token-aware variant;
shell quoting/escaping is not promised unless the implementation actually parses shell syntax.

That framing would make the feature useful without weakening the current prefix-rule model.

GTOL · 3 months ago

I’m open to this suggestion.

For example, in Maven you can chain lifecycle phases, such as mvn clean test or mvn clean test deploy, with any number of phases between test and deploy. If I allow any mvn command to be auto-approved, Codex could simply append deploy to the command, causing my code to be accidentally deployed to a remote server.

For me I hope at least they add the exact_match_rule.