Codex App: allow a custom diff command for the Review pane

What variant of Codex are you using?

Codex App

What feature would you like to see?

Allow a project to configure a custom command that supplies a unified diff to the built-in Review pane.

For example:

[review]
diff_command = "./tools/codex-diff"

Codex would run the command from the project root and parse its stdout as a standard unified diff.

This would allow the existing Review pane to display changes in projects that are not backed by Git.

Problem

The Review pane currently requires a Git repository.

Codex can successfully edit files in projects managed by other version control or snapshot systems, but those changes do not appear in the built-in Review pane.

In these environments, it is already possible to produce a valid unified diff using an external command. There is currently no documented way to pass that diff to the Codex App UI.

Minimal expected behavior

1. The project config specifies a diff command.
2. Codex runs the command from the project root.
3. The command writes a standard unified diff to stdout.
4. Codex parses the diff and displays its files and hunks in the existing Review pane.
5. Codex reruns the command when the user refreshes the Review pane.

The command should receive the project root through its working directory or an environment variable.

A non-zero exit code could be displayed as a provider error in the Review pane.

Out of scope

This request does not require:

• custom commit or branch operations
• staging support
• custom workspace or worktree creation
• history navigation
• push or pull operations
• file or hunk revert support

Those capabilities could be considered separately.

The initial feature only needs to make an externally generated unified diff visible in the built-in Review pane.

Why this approach?

A custom diff command is significantly smaller than a complete pluggable VCS abstraction.

It would support many non-Git workflows without requiring Codex to understand their revision, branch, workspace, or synchronization models.

Git could remain the default implementation with no behavior changes for existing projects.

Related issue

• #31167 requests broader support for alternative VCS frontends, including diff and review context.

This request is intentionally narrower: it only asks for a custom source of unified diff data for the existing Review pane.