Separate the final tree from the generating process
The pull request tells you what changed. The recorded run tells you how the change was produced. Review both without treating either as a substitute for the other. Use the run to identify the commands that edited or generated files, the validation steps that followed, and unexpected side effects; use the diff and repository history to decide whether the resulting code is correct.
Reconstruct the validation chain, including failures
A final “tests passed” statement is less useful than the actual command sequence. Check which test or build commands ran, whether an earlier attempt failed, whether the agent changed code after the last successful validation, and whether the command exited cleanly. Retaining failures is valuable because they explain why the agent changed direction and can reveal coverage gaps that a final green command hides.
Review file scope as reads, writes, creates, renames, and deletes
Compare the task scope with the observed paths. Repository reads are normal for exploration, while writes and deletes deserve closer attribution to the command or tool phase that caused them. Pay special attention to paths outside the repository, generated files, home-directory configuration, temporary directories, and caches. External-path activity is not automatically wrong, but it should be explainable.
Record external services that influenced the patch
Model providers are only one network dependency. Package registries, Git hosting, documentation sites, local development servers, and MCP services can all influence the run. If the review question involves provenance or reproducibility, note which remote destinations were contacted and which command or phase initiated them. A network destination is context for review, not a claim that the returned content was malicious or correct.
Reduce the run into a decision-oriented artifact
A reviewer rarely needs every captured event. Keep the task and version, important commands and exit status, relevant file effects, remote destinations that affected the decision, major retries, and unresolved questions. Preserve timestamps or stable run identifiers so another engineer can return to the original session. Redact prompts, responses, headers, path contents, and other sensitive material before sharing.
Keep negative claims bounded by the capture
A recorded run can show that an observed command executed or an observed path was touched. It cannot prove that activity outside the recording scope never occurred. Process and file capture can also be incomplete when the environment, privileges, runtime, or probe coverage changes. Phrase review findings as observed behavior in a specific run and reproduce surprising behavior before escalating it.
$ sudo agentsight record -- codex
$ agentsight report audit --json
$ agentsight report export -o review-run.json