mirror of
https://github.com/openai/codex.git
synced 2026-04-27 16:15:09 +00:00
## Why `argument-comment-lint` was green in CI even though the repo still had many uncommented literal arguments. The main gap was target coverage: the repo wrapper did not force Cargo to inspect test-only call sites, so examples like the `latest_session_lookup_params(true, ...)` tests in `codex-rs/tui_app_server/src/lib.rs` never entered the blocking CI path. This change cleans up the existing backlog, makes the default repo lint path cover all Cargo targets, and starts rolling that stricter CI enforcement out on the platform where it is currently validated. ## What changed - mechanically fixed existing `argument-comment-lint` violations across the `codex-rs` workspace, including tests, examples, and benches - updated `tools/argument-comment-lint/run-prebuilt-linter.sh` and `tools/argument-comment-lint/run.sh` so non-`--fix` runs default to `--all-targets` unless the caller explicitly narrows the target set - fixed both wrappers so forwarded cargo arguments after `--` are preserved with a single separator - documented the new default behavior in `tools/argument-comment-lint/README.md` - updated `rust-ci` so the macOS lint lane keeps the plain wrapper invocation and therefore enforces `--all-targets`, while Linux and Windows temporarily pass `-- --lib --bins` That temporary CI split keeps the stricter all-targets check where it is already cleaned up, while leaving room to finish the remaining Linux- and Windows-specific target-gated cleanup before enabling `--all-targets` on those runners. The Linux and Windows failures on the intermediate revision were caused by the wrapper forwarding bug, not by additional lint findings in those lanes. ## Validation - `bash -n tools/argument-comment-lint/run.sh` - `bash -n tools/argument-comment-lint/run-prebuilt-linter.sh` - shell-level wrapper forwarding check for `-- --lib --bins` - shell-level wrapper forwarding check for `-- --tests` - `just argument-comment-lint` - `cargo test` in `tools/argument-comment-lint` - `cargo test -p codex-terminal-detection` ## Follow-up - Clean up remaining Linux-only target-gated callsites, then switch the Linux lint lane back to the plain wrapper invocation. - Clean up remaining Windows-only target-gated callsites, then switch the Windows lint lane back to the plain wrapper invocation.
codex-execpolicy
Overview
- Policy engine and CLI built around
prefix_rule(pattern=[...], decision?, justification?, match?, not_match?)plushost_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
patternelement may be a list to denote alternatives.decisiondefaults toallow; valid values:allow,prompt,forbidden. justificationis an optional human-readable rationale for why a rule exists. It can be provided for anydecisionand may be surfaced in different contexts (for example, in approval prompts or rejection messages). Whendecision = "forbidden"is used, include a recommended alternative in thejustification, when appropriate (e.g.,"Use `jj` instead of `git`.").match/not_matchsupply example invocations that are validated at load time (think of them as unit tests); examples can be token arrays or strings (strings are tokenized withshlex).- 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 statusonly 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/gitto basename rules forgit. - 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 checksubcommand with one or more policy files (for examplesrc/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
--rulesflags to merge rules, evaluated in the order provided, and use--prettyfor 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":[]}
- Match:
Response shape
{
"matchedRules": [
{
"prefixRuleMatch": {
"matchedPrefix": ["<token>", "..."],
"decision": "allow|prompt|forbidden",
"resolvedProgram": "/absolute/path/to/program",
"justification": "..."
}
}
],
"decision": "allow|prompt|forbidden"
}
- When no rules match,
matchedRulesis an empty array anddecisionis omitted. matchedRuleslists every rule whose prefix matched the command;matchedPrefixis the exact prefix that matched.resolvedProgramis omitted unless an absolute executable path matched via basename fallback.- The effective
decisionis 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.