core-agent-ide/codex-rs/execpolicy
Michael Bolin b77fe8fefe
Apply argument comment lint across codex-rs (#14652)
## Why

Once the repo-local lint exists, `codex-rs` needs to follow the
checked-in convention and CI needs to keep it from drifting. This commit
applies the fallback `/*param*/` style consistently across existing
positional literal call sites without changing those APIs.

The longer-term preference is still to avoid APIs that require comments
by choosing clearer parameter types and call shapes. This PR is
intentionally the mechanical follow-through for the places where the
existing signatures stay in place.

After rebasing onto newer `main`, the rollout also had to cover newly
introduced `tui_app_server` call sites. That made it clear the first cut
of the CI job was too expensive for the common path: it was spending
almost as much time installing `cargo-dylint` and re-testing the lint
crate as a representative test job spends running product tests. The CI
update keeps the full workspace enforcement but trims that extra
overhead from ordinary `codex-rs` PRs.

## What changed

- keep a dedicated `argument_comment_lint` job in `rust-ci`
- mechanically annotate remaining opaque positional literals across
`codex-rs` with exact `/*param*/` comments, including the rebased
`tui_app_server` call sites that now fall under the lint
- keep the checked-in style aligned with the lint policy by using
`/*param*/` and leaving string and char literals uncommented
- cache `cargo-dylint`, `dylint-link`, and the relevant Cargo
registry/git metadata in the lint job
- split changed-path detection so the lint crate's own `cargo test` step
runs only when `tools/argument-comment-lint/*` or `rust-ci.yml` changes
- continue to run the repo wrapper over the `codex-rs` workspace, so
product-code enforcement is unchanged

Most of the code changes in this commit are intentionally mechanical
comment rewrites or insertions driven by the lint itself.

## Verification

- `./tools/argument-comment-lint/run.sh --workspace`
- `cargo test -p codex-tui-app-server -p codex-tui`
- parsed `.github/workflows/rust-ci.yml` locally with PyYAML

---

* -> #14652
* #14651
2026-03-16 16:48:15 -07:00
..
examples feat: add justification arg to prefix_rule() in *.rules (#8751) 2026-01-05 21:24:48 +00:00
src Apply argument comment lint across codex-rs (#14652) 2026-03-16 16:48:15 -07:00
tests execpolicy: add host_executable() path mappings (#12964) 2026-02-27 12:59:24 -08:00
BUILD.bazel feat: add support for building with Bazel (#8875) 2026-01-09 11:09:43 -08:00
Cargo.toml execpolicy: add host_executable() path mappings (#12964) 2026-02-27 12:59:24 -08:00
README.md execpolicy: add host_executable() path mappings (#12964) 2026-02-27 12:59:24 -08:00

codex-execpolicy

Overview

  • Policy engine and CLI built around prefix_rule(pattern=[...], decision?, justification?, match?, not_match?) plus host_executable(name=..., paths=[...]).
  • This release covers the prefix-rule subset of the execpolicy language plus host executable metadata; a richer language will follow.
  • Tokens are matched in order; any pattern element may be a list to denote alternatives. decision defaults to allow; valid values: allow, prompt, forbidden.
  • justification is an optional human-readable rationale for why a rule exists. It can be provided for any decision and may be surfaced in different contexts (for example, in approval prompts or rejection messages). When decision = "forbidden" is used, include a recommended alternative in the justification, when appropriate (e.g., "Use `jj` instead of `git`.").
  • match / not_match supply example invocations that are validated at load time (think of them as unit tests); examples can be token arrays or strings (strings are tokenized with shlex).
  • The CLI always prints the JSON serialization of the evaluation result.
  • The legacy rule matcher lives in codex-execpolicy-legacy.

Policy shapes

  • Prefix rules use Starlark syntax:
prefix_rule(
    pattern = ["cmd", ["alt1", "alt2"]], # ordered tokens; list entries denote alternatives
    decision = "prompt",                 # allow | prompt | forbidden; defaults to allow
    justification = "explain why this rule exists",
    match = [["cmd", "alt1"], "cmd alt2"],           # examples that must match this rule
    not_match = [["cmd", "oops"], "cmd alt3"],       # examples that must not match this rule
)
  • Host executable metadata can optionally constrain which absolute paths may resolve through basename rules:
host_executable(
    name = "git",
    paths = [
        "/opt/homebrew/bin/git",
        "/usr/bin/git",
    ],
)
  • Matching semantics:
    • execpolicy always tries exact first-token matches first.
    • With host-executable resolution disabled, /usr/bin/git status only matches a rule whose first token is /usr/bin/git.
    • With host-executable resolution enabled, if no exact rule matches, execpolicy may fall back from /usr/bin/git to basename rules for git.
    • If host_executable(name="git", ...) exists, basename fallback is only allowed for listed absolute paths.
    • If no host_executable() entry exists for a basename, basename fallback is allowed.

CLI

  • From the Codex CLI, run codex execpolicy check subcommand with one or more policy files (for example src/default.rules) to check a command:
codex execpolicy check --rules path/to/policy.rules git status
  • To opt into basename fallback for absolute program paths, pass --resolve-host-executables:
codex execpolicy check \
  --rules path/to/policy.rules \
  --resolve-host-executables \
  /usr/bin/git status
  • Pass multiple --rules flags to merge rules, evaluated in the order provided, and use --pretty for formatted JSON.
  • You can also run the standalone dev binary directly during development:
cargo run -p codex-execpolicy -- check --rules path/to/policy.rules git status
  • Example outcomes:
    • Match: {"matchedRules":[{...}],"decision":"allow"}
    • No match: {"matchedRules":[]}

Response shape

{
  "matchedRules": [
    {
      "prefixRuleMatch": {
        "matchedPrefix": ["<token>", "..."],
        "decision": "allow|prompt|forbidden",
        "resolvedProgram": "/absolute/path/to/program",
        "justification": "..."
      }
    }
  ],
  "decision": "allow|prompt|forbidden"
}
  • When no rules match, matchedRules is an empty array and decision is omitted.
  • matchedRules lists every rule whose prefix matched the command; matchedPrefix is the exact prefix that matched.
  • resolvedProgram is omitted unless an absolute executable path matched via basename fallback.
  • The effective decision is the strictest severity across all matches (forbidden > prompt > allow).

Note: execpolicy commands are still in preview. The API may have breaking changes in the future.