Add path-scoped review filters to codex exec review

Resolved 💬 1 comment Opened Mar 11, 2026 by 0xble Closed Apr 18, 2026

Summary

Add path-scoped review filtering to codex exec review and the app-server review APIs.

Proposed usage:

  • codex exec review --paths src/lib.rs src/main.rs --uncommitted
  • codex exec review --paths src/lib.rs --paths src/main.rs --uncommitted
  • codex exec review --pathspec-from-file review-paths.txt --uncommitted
  • codex exec review --paths src/lib.rs src/main.rs -- "focus on reviewer ergonomics"

Motivation

Users often want review on a narrow part of the repo rather than the full diff. The goal is to make that scope explicit and reliable without changing the overall review flow.

Proposed behavior

Path filters should:

  • be interpreted relative to the repository root
  • remain correct when review starts from a nested cwd
  • be rendered as literal Git path filters rather than accidentally invoking Git pathspec magic

Implementation notes

The cleanest design is to keep transport thin and centralize pathscope semantics in core review prompt construction:

  • add pathspecs to review request transport surfaces
  • add listable --paths and --pathspec-from-file
  • normalize and validate path inputs in core
  • resolve nested-cwd inputs back to repo-root-relative paths
  • reject paths that escape the repo root
  • render safe Git filters such as :(top,literal)... and :(top,glob)**
  • generate scoped user-facing hints and prompt guidance from one place

Validation

A working implementation is available here:

That PR is for my personal use right now, and I am using it locally from my fork rather than submitting it as an upstream PR.

That PR includes passing targeted tests for repo-root scoping, validation/rejection cases, CLI parsing, pathspec-file handling, and app-server entered-review-mode behavior.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗