BuildGist

How to review what Codex changed

Kayvan Zahiri ·

To review what Codex changed, run git status and git diff in the project folder, read the risky files first, and read BuildGist's explanation of that run in your Inbox when the run was one BuildGist explains.

Start from the working tree

Codex edits the folder you opened it in. Those edits are ordinary Git changes. Nobody has to commit, push, or add a remote before you can read them. In the project folder:

git status
git diff --stat
git diff

git status lists the files. It also lists files you had already changed before Codex ran, so commit or stash your own edits first if you want the list to be only this run. Files Codex created show up as untracked until they are added. git diff is what is not staged yet. git diff HEAD is everything since the last commit, staged or not.

The same commands are how you read a Claude Code or Cursor run. The agent name does not change the diff. A walk-through of the commands, including commits made during a run, is in what did Claude Code change?

Read commits Codex made

Codex sometimes commits during a run. Those commits are not in git diff once they are committed. They are in the log:

git log --oneline -5
git show

git show with no id shows the latest commit. Pass a commit id from the log to read an earlier one. Read the message, then the patch. A commit message that restates your request is not evidence the patch does only that. The patch is the review.

If the log has several commits from the run, read them from oldest to newest so you see the change build, or read git diff from the commit before the run to HEAD if you want one combined patch. Either way you are looking at lines Codex left in the repository, not at a summary of the chat.

Read in order of risk

Start where a small change has large consequences, then read the rest.

  1. Sign-in, sessions and permissions. A one-line change to a check can matter more than a long rewrite of a readme.
  2. Anything that deletes, overwrites or sends data.
  3. Payments.
  4. New dependencies, and changes to a lockfile or a manifest.
  5. Configuration, including CI config and anything that calls a new external service.
  6. Interface text and docs last.

For each important change, finish the sentence "Now a user can ...". If you cannot, that file is the one to keep reading. Ask Codex about that file, not for a retelling of the whole run.

What an explanation adds

BuildGist explains each meaningful Claude Code, Cursor and Codex run in plain English, flags concerns, and puts the explanation in your Inbox. Small changes stay quiet. Comment-only, formatting-only and docs-only changes are not explained. Dependency manifests, migrations, auth paths, API routes, CI config and new external service references are.

The explanation says what changed, what it means and what to check. It is written by AI, so check important behavior against the code and tests. An explanation can include edits you made by hand between agent turns. A file you and Codex both edited is described as Codex's work. If you need only Codex's lines, read git diff and set aside the hunks you recognize as yours.

The home page's worked example is a Claude Code run, shortened and edited, not a Codex run. The review questions are the same. The request was "Add login with Google." 7 files changed, +224 -16. In plain words: the sign-in button, where Google sends you back, the browser's signed-in status, and deleting a note. Google checks who visitors are and vouches for them, so the app never sees passwords. The name for that is the OpenID Connect (OIDC) authorization code flow. The high concern: any signed-in user can delete anyone else's note, because nothing checks that the note is yours. Sign-in working does not show that. You would see it by reading the delete path in the diff, or by reading the concern and then checking that path.

Which of the diff and the explanation to read, and when the diff is enough on its own, is in BuildGist or the git diff.

Codex and BuildGist

Codex needs you to approve BuildGist once, in Codex. BuildGist shows the steps. The diff is yours to read either way. Setup is in Getting started.

BuildGist does not send your whole repository, files the run did not change, or files named like secrets, such as .env files and keys. The diff on your machine still shows those files if they are in the working tree and not ignored. Secret masking is best-effort. If a secret might be in a file the run changed, read that file yourself before you trust either the diff view you paste into a chat or an explanation.

After the read

  1. git status and git diff --stat, for the file list and the size of each change.
  2. git log --oneline -5, if Codex may have committed.
  3. Read auth, deletion, payments, dependencies and configuration before anything else.
  4. Write one sentence for each important change, starting "Now a user can".
  5. Run the tests that cover those sentences. A test Codex already ran is a lead. Run it yourself before you treat the change as reviewed.
  6. Before you merge, use how to review AI-generated code before you merge. The note to paste into another agent is the task, the sentences, and the next step.

What you need

Codex needs you to approve BuildGist once, in Codex. BuildGist shows the steps. Setup is in Getting started.

To explain a run, your computer sends BuildGist what that run needs, and BuildGist passes it to Anthropic. BuildGist does not keep this material. It does not send your whole repository, files the run did not change, or files named like secrets, such as .env files and keys. It keeps the explanation and short cited excerpts of changed code, at most 12 lines each. Secret masking is best-effort. Privacy has the full list.

Every account gets 7 days of BuildGist Pro free, with no card. The 7 days start at your first explanation or Continue handoff. Nobody is charged when the trial ends. After that, BuildGist Pro is $12 per month, plus any applicable tax shown at checkout. See pricing.

Try BuildGist

Apple silicon, macOS 12 or later. United States, 18 or older.

Related

Questions: kayvanandre@gmail.com.