25 Commits

• execpolicy: add host_executable() path mappings (#12964)

  ## Why
  
  `execpolicy` currently keys `prefix_rule()` matching off the literal
  first token. That works for rules like `["/usr/bin/git"]`, but it means
  shared basename rules such as `["git"]` do not help when a caller passes
  an absolute executable path like `/usr/bin/git`.
  
  This PR lays the groundwork for basename-aware matching without changing
  existing callers yet. It adds typed host-executable metadata and an
  opt-in resolution path in `codex-execpolicy`, so a follow-up PR can
  adopt the new behavior in `unix_escalation.rs` and other call sites
  without having to redesign the policy layer first.
  
  ## What Changed
  
  - added `host_executable(name = ..., paths = [...])` to the execpolicy
  parser and validated it with `AbsolutePathBuf`
  - stored host executable mappings separately from prefix rules inside
  `Policy`
  - added `MatchOptions` and opt-in `*_with_options()` APIs that preserve
  existing behavior by default
  - implemented exact-first matching with optional basename fallback,
  gated by `host_executable()` allowlists when present
  - normalized executable names for cross-platform matching so Windows
  paths like `git.exe` can satisfy `host_executable(name = "git", ...)`
  - updated `match` / `not_match` example validation to exercise the
  host-executable resolution path instead of only raw prefix-rule matching
  - preserved source locations for deferred example-validation errors so
  policy load failures still point at the right file and line
  - surfaced `resolvedProgram` on `RuleMatch` so callers can tell when a
  basename rule matched an absolute executable path
  - preserved host executable metadata when requirements policies overlay
  file-based policies in `core/src/exec_policy.rs`
  - documented the new rule shape and CLI behavior in
  `execpolicy/README.md`
  
  ## Verification
  
  - `cargo test -p codex-execpolicy`
  - added coverage in `execpolicy/tests/basic.rs` for parsing, precedence,
  empty allowlists, basename fallback, exact-match precedence, and
  host-executable-backed `match` / `not_match` examples
  - added a regression test in `core/src/exec_policy.rs` to verify
  requirements overlays preserve `host_executable()` metadata
  - verified `cargo test -p codex-core --lib`, including source-rendering
  coverage for deferred validation errors

  Michael Bolin · 2026-02-27 12:59:24 -08:00
  b148d98e0e
• feat(core): persist network approvals in execpolicy (#12357)

  ## Summary
  Persist network approval allow/deny decisions as `network_rule(...)`
  entries in execpolicy (not proxy config)
  
  It adds `network_rule` parsing + append support in `codex-execpolicy`,
  including `decision="prompt"` (parse-only; not compiled into proxy
  allow/deny lists)
  - compile execpolicy network rules into proxy allow/deny lists and
  update the live proxy state on approval
  - preserve requirements execpolicy `network_rule(...)` entries when
  merging with file-based execpolicy
  - reject broad wildcard hosts (for example `*`) for persisted
  `network_rule(...)`

  viyatb-oai · 2026-02-23 21:37:46 -08:00
  c3048ff90a
• fix(core) Deduplicate prefix_rules before appending (#10309)

  ## Summary
  We ideally shouldn't make it to this point in the first place, but if we
  do try to append a rule that already exists, we shouldn't append the
  same rule twice.
  
  ## Testing
  - [x] Added unit test for this case

  Dylan Hurd · 2026-02-01 20:30:38 -08:00
  6c22360bcb
• feat(core) RequestRule (#9489)

  ## Summary
  Instead of trying to derive the prefix_rule for a command mechanically,
  let's let the model decide for us.
  
  ## Testing
  - [x] tested locally

  Dylan Hurd · 2026-01-28 08:43:17 +00:00
  996e09ca24
• Another round of improvements for config error messages (#9746)

  In a [recent PR](https://github.com/openai/codex/pull/9182), I made some
  improvements to config error messages so errors didn't leave app server
  clients in a dead state. This is a follow-on PR to make these error
  messages more readable and actionable for both TUI and GUI users. For
  example, see #9668 where the user was understandably confused about the
  source of the problem and how to fix it.
  
  The improved error message:
  1. Clearly identifies the config file where the error was found (which
  is more important now that we support layered configs)
  2. Provides a line and column number of the error
  3. Displays the line where the error occurred and underlines it
  
  For example, if my `config.toml` includes the following:
  ```toml
  [features]
  collaboration_modes = "true"
  ```
  
  Here's the current CLI error message:
  ```
  Error loading config.toml: invalid type: string "true", expected a boolean in `features`
  ```
  
  And here's the improved message:
  ```
  Error loading config.toml:
  /Users/etraut/.codex/config.toml:43:23: invalid type: string "true", expected a boolean
     |
  43 | collaboration_modes = "true"
     |                       ^^^^^^
  ```
  
  The bulk of the new logic is contained within a new module
  `config_loader/diagnostics.rs` that is responsible for calculating the
  text range for a given toml path (which is more involved than I would
  have expected).
  
  In addition, this PR adds the file name and text range to the
  `ConfigWarningNotification` app server struct. This allows GUI clients
  to present the user with a better error message and an optional link to
  open the errant config file. This was a suggestion from @.bolinfest when
  he reviewed my previous PR.

  Eric Traut · 2026-01-23 20:11:09 -08:00
  713ae22c04
• fix: prompt for unsafe commands on Windows (#9117)
  Michael Bolin · 2026-01-12 21:30:09 -08:00
  ddae70bd62
• feat: add justification arg to prefix_rule() in *.rules (#8751)

  Adds an optional `justification` parameter to the `prefix_rule()`
  execpolicy DSL so policy authors can attach human-readable rationale to
  a rule. That justification is propagated through parsing/matching and
  can be surfaced to the model (or approval UI) when a command is blocked
  or requires approval.
  
  When a command is rejected (or gated behind approval) due to policy, a
  generic message makes it hard for the model/user to understand what went
  wrong and what to do instead. Allowing policy authors to supply a short
  justification improves debuggability and helps guide the model toward
  compliant alternatives.
  
  Example:
  
  ```python
  prefix_rule(
      pattern = ["git", "push"],
      decision = "forbidden",
      justification = "pushing is blocked in this repo",
  )
  ```
  
  If Codex tried to run `git push origin main`, now the failure would
  include:
  
  ```
  `git push origin main` rejected: pushing is blocked in this repo
  ```
  
  whereas previously, all it was told was:
  
  ```
  execpolicy forbids this command
  ```

  Michael Bolin · 2026-01-05 21:24:48 +00:00
  cafb07fe6e
• fix: policy/*.codexpolicy -> rules/*.rules (#7888)

  We decided that `*.rules` is a more fitting (and concise) file extension
  than `*.codexpolicy`, so we are changing the file extension for the
  "execpolicy" effort. We are also changing the subfolder of `$CODEX_HOME`
  from `policy` to `rules` to match.
  
  This PR updates the in-repo docs and we will update the public docs once
  the next CLI release goes out.
  
  Locally, I created `~/.codex/rules/default.rules` with the following
  contents:
  
  ```
  prefix_rule(pattern=["gh", "pr", "view"])
  ```
  
  And then I asked Codex to run:
  
  ```
  gh pr view 7888 --json title,body,comments
  ```
  
  and it was able to!

  Michael Bolin · 2025-12-11 14:46:00 -08:00
  e0d7ac51d3
• Refactor execpolicy fallback evaluation (#7544)

  ## Refactor of the `execpolicy` crate
  
  To illustrate why we need this refactor, consider an agent attempting to
  run `apple | rm -rf ./`. Suppose `apple` is allowed by `execpolicy`.
  Before this PR, `execpolicy` would consider `apple` and `pear` and only
  render one rule match: `Allow`. We would skip any heuristics checks on
  `rm -rf ./` and immediately approve `apple | rm -rf ./` to run.
  
  To fix this, we now thread a `fallback` evaluation function into
  `execpolicy` that runs when no `execpolicy` rules match a given command.
  In our example, we would run `fallback` on `rm -rf ./` and prevent
  `apple | rm -rf ./` from being run without approval.

  zhao-oai · 2025-12-03 23:39:48 -08:00
  3d35cb4619
• execpolicy helpers (#7032)

  this PR 
  - adds a helper function to amend `.codexpolicy` files with new prefix
  rules
  - adds a utility to `Policy` allowing prefix rules to be added to
  existing `Policy` structs
  
  both additions will be helpful as we thread codexpolicy into the TUI
  workflow

  zhao-oai · 2025-12-02 15:05:27 -05:00
  1d09ac89a1
• execpolicycheck command in codex cli (#7012)

  adding execpolicycheck tool onto codex cli
  
  this is useful for validating policies (can be multiple) against
  commands.
  
  it will also surface errors in policy syntax:
  <img width="1150" height="281" alt="Screenshot 2025-11-19 at 12 46
  21 PM"
  src="https://github.com/user-attachments/assets/8f99b403-564c-4172-acc9-6574a8d13dc3"
  />
  
  this PR also changes output format when there's no match in the CLI.
  instead of returning the raw string `noMatch`, we return
  `{"noMatch":{}}`
  
  this PR is a rewrite of: https://github.com/openai/codex/pull/6932 (due
  to the numerous merge conflicts present in the original PR)
  
  ---------
  
  Co-authored-by: Michael Bolin <mbolin@openai.com>

  zhao-oai · 2025-11-20 16:44:31 -05:00
  fe7a3f0c2b
• migrating execpolicy -> execpolicy-legacy and execpolicy2 -> execpolicy (#6956)
  zhao-oai · 2025-11-19 19:14:10 -08:00
  fb9849e1e3
• Use anyhow::Result in tests for error propagation (#4105)
  pakrym-oai · 2025-09-23 13:31:36 -07:00
  0f9a796617
• chore: clippy on redundant closure (#4058)

  Add redundant closure clippy rules and let Codex fix it by minimising
  FQP

  jif-oai · 2025-09-22 19:30:16 +00:00
  be366a31ab
• chore: enable clippy::redundant_clone (#3489)

  Created this PR by:
  
  - adding `redundant_clone` to `[workspace.lints.clippy]` in
  `cargo-rs/Cargol.toml`
  - running `cargo clippy --tests --fix`
  - running `just fmt`
  
  Though I had to clean up one instance of the following that resulted:
  
  ```rust
  let codex = codex;
  ```

  Michael Bolin · 2025-09-11 11:59:37 -07:00
  bec51f6c05
• chore: upgrade to Rust 1.89 (#2465)

  Codex created this PR from the following prompt:
  
  > upgrade this entire repo to Rust 1.89. Note that this requires
  updating codex-rs/rust-toolchain.toml as well as the workflows in
  .github/. Make sure that things are "clippy clean" as this change will
  likely uncover new Clippy errors. `just fmt` and `cargo clippy --tests`
  are sufficient to check for correctness
  
  Note this modifies a lot of lines because it folds nested `if`
  statements using `&&`.
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/2465).
  * #2467
  * __->__ #2465

  Michael Bolin · 2025-08-19 13:22:02 -07:00
  50c48e88f5
• Added allow-expect-in-tests / allow-unwrap-in-tests (#2328)

  This PR:
  * Added the clippy.toml to configure allowable expect / unwrap usage in
  tests
  * Removed as many expect/allow lines as possible from tests
  * moved a bunch of allows to expects where possible
  
  Note: in integration tests, non `#[test]` helper functions are not
  covered by this so we had to leave a few lingering `expect(expect_used`
  checks around

  Parker Thompson · 2025-08-14 17:59:01 -07:00
  a075424437
• chore(rs): update dependencies (#1494)

  ### Chores
  - Update cargo dependencies
  - Remove unused cargo dependencies
  - Fix clippy warnings
  - Update Dockerfile (package.json requires node 22)
  - Let Dependabot update bun, cargo, devcontainers, docker,
  github-actions, npm (nix still not supported)
  
  ### TODO
  - Upgrade dependencies with breaking changes
  
  ```shell
  $ cargo update --verbose
     Unchanged crossterm v0.28.1 (available: v0.29.0)
     Unchanged schemars v0.8.22 (available: v1.0.4)
  ```

  Rene Leonhardt · 2025-07-10 11:08:16 -07:00
  82b0cebe8b
• chore: replace regex with regex-lite, where appropriate (#1200)

  As explained on https://crates.io/crates/regex-lite, `regex-lite` is a
  lighter alternative to `regex` and seems to be sufficient for our
  purposes.

  Michael Bolin · 2025-06-02 17:11:45 -07:00
  5a5aa89914
• Add codespell support (config, workflow to detect/not fix) and make it fix some typos (#903)

  More about codespell: https://github.com/codespell-project/codespell .
  
  I personally introduced it to dozens if not hundreds of projects already
  and so far only positive feedback.
  
  CI workflow has 'permissions' set only to 'read' so also should be safe.
  
  Let me know if just want to take typo fixes in and get rid of the CI
  
  ---------
  
  Signed-off-by: Yaroslav O. Halchenko <debian@onerussian.com>

  Yaroslav Halchenko · 2025-05-14 09:39:49 -07:00
  327cf41f0f
• fix: enable clippy on tests (#870)

  https://github.com/openai/codex/pull/855 added the clippy warning to
  disallow `unwrap()`, but apparently we were not verifying that tests
  were "clippy clean" in CI, so I ended up with a lot of local errors in
  VS Code.
  
  This turns on the check in CI and fixes the offenders.

  Michael Bolin · 2025-05-08 16:02:56 -07:00
  a9adb4175c
• Workspace lints and disallow unwrap (#855)

  Sets submodules to use workspace lints. Added denying unwrap as a
  workspace level lint, which found a couple of cases where we could have
  propagated errors. Also manually labeled ones that were fine by my eye.

  jcoens-openai · 2025-05-08 09:46:18 -07:00
  87cf120873
• Update cargo to 2024 edition (#842)

  Some effects of this change:
  - New formatting changes across many files. No functionality changes
  should occur from that.
  - Calls to `set_env` are considered unsafe, since this only happens in
  tests we wrap them in `unsafe` blocks

  jcoens-openai · 2025-05-07 08:37:48 -07:00
  8a89d3aeda
• fix: small fixes so Codex compiles on Windows (#673)

  Small fixes required:
  
  * `ExitStatusExt` differs because UNIX expects exit code to be `i32`
  whereas Windows does `u32`
  * Marking a file "executable only by owner" is a bit more involved on
  Windows. We just do something approximate for now (and add a TODO) to
  get things compiling.
  
  I created this PR on my personal Windows machine and `cargo test` and
  `cargo clippy` succeed. Once this is in, I'll rebase
  https://github.com/openai/codex/pull/665 on top so Windows stays fixed!

  Michael Bolin · 2025-04-25 15:58:44 -07:00
  c18f1689a9
• feat: introduce codex_execpolicy crate for defining "safe" commands (#634)

  As described in detail in `codex-rs/execpolicy/README.md` introduced in
  this PR, `execpolicy` is a tool that lets you define a set of _patterns_
  used to match [`execv(3)`](https://linux.die.net/man/3/execv)
  invocations. When a pattern is matched, `execpolicy` returns the parsed
  version in a structured form that is amenable to static analysis.
  
  The primary use case is to define patterns match commands that should be
  auto-approved by a tool such as Codex. This supports a richer pattern
  matching mechanism that the sort of prefix-matching we have done to
  date, e.g.:
  
  
  https://github.com/openai/codex/blob/5e40d9d2211737f46136610497bcd9a8271009e0/codex-cli/src/approvals.ts#L333-L354
  
  Note we are still playing with the API and the `system_path` option in
  particular still needs some work.

  Michael Bolin · 2025-04-24 17:14:47 -07:00
  58f0e5ab74