Skip to main content
When a curation operation is flagged for review, you can manage it through the CLI or the local web UI. Both interfaces operate on the same underlying review state — changes made in one are immediately reflected in the other.

​
CLI commands

​
List pending reviews

This lists all pending review operations for the current project, grouped by task:
Each entry shows:
  • Operation type — DELETE, UPDATE, UPSERT, MERGE, or ADD
  • Impact level — HIGH IMPACT operations are labeled
  • Path — The context tree file or folder affected
  • Why — The reason the agent curated this change
  • Before / After — Summaries of the content before and after the change
If there are no pending reviews, the command exits cleanly with a “No pending reviews” message.

​
Approve changes

Accept the curated changes and make them eligible for brv push:
On approval, the backup is deleted and the current file content becomes the new baseline.

​
Reject changes

Roll back the curated changes and restore the previous content from backup:
On rejection:
  • UPDATE / UPSERT — The file is restored to its pre-change content.
  • DELETE — The deleted file (or folder contents) is restored to disk.
  • MERGE — Both the target file and the deleted source file are restored.
  • ADD — The newly created file is removed.

​
Selective review with --file

You don’t have to approve or reject an entire task at once. Use the --file flag to act on specific files:
File paths are relative to the context tree root (as shown in brv review pending output).

​
JSON output

All review commands support --format json for structured output:

​
Disable the review log

For unattended workflows — --detach curates, autonomous agents, headless CI — the high-impact review prompt may be more noise than signal. You can turn the HITL review log off for the current project:
When the review log is disabled for a project:
  • brv curate (sync mode) no longer prints the “N operations require review” prompt.
  • Curate-log entries written in --detach mode no longer carry the per-operation review marker.
  • brv dream no longer surfaces its own needsReview operations as pending reviews.
  • brv review pending lists no new entries until the log is re-enabled.
  • No review backups are written, since there is nothing to roll back from.
The setting is project-scoped and persists across CLI and daemon restarts. brv review with no flags prints the current state (also available via --format json).
Disabling the log only affects new operations. Pending reviews created before you disabled the log remain visible in brv review pending and can still be approved or rejected.

​
Command reference

​
Local web UI

Pending agent edits inline in the Changes tab Pending reviews appear inline in the Changes tab of brv webui, alongside your own staged and unstaged changes — there is no separate review interface. Each agent-generated file carries an op-type badge (ADD / UPDATE / UPSERT / MERGE / DELETE), an impact badge (low impact / high impact), and the agent’s reason for the change. Approve and reject map onto the buttons already in the Changes tab:
  • Stage a pending file approves the agent’s edit (and Stage all approves every pending file in the bucket).
  • Discard a pending file rejects the edit and rolls it back from the backup. For an agent file, this skips the usual “discard your work?” confirmation.
The dashboard links to http://localhost:<webui-port>/changes?project=<project> so notifications deep-link to the right project automatically. To turn the whole flow off for a project, run brv review --disable.
The web UI and CLI share the same review state. Approve a file in the Changes tab and reject another via brv review reject — both reflect immediately on the other side.

​
Review and push

Files with pending reviews are excluded from brv push. You must resolve all reviews before pushing:
If you run brv push while reviews are pending, only the approved and non-reviewed files are pushed. Pending and rejected files are held back.