Reviewing changes
Review what an agent produced and merge it into your project — the gate every change passes through.
When a session finishes work, the agent opens a change request — a summary and the exact diff of what it changed. Nothing reaches your project's main branch until you merge it. This is how you keep the good work and discard the rest.
Review a change request
Open the change request
A finished session surfaces its change request from the session itself, and every project's change requests are listed under Customize → Changes. Open one to see its title, summary, and the files it touches.
Read the diff
Go through the diff file by file — additions, deletions, and edits are highlighted. This is the agent's actual proposed work, not a description of it, so you're reviewing exactly what would land.
Merge, or ask for changes
If it's good, merge — the changes land on your default branch and the change request closes. If it's not, leave it open and go back to the session to tell the agent what to fix; it'll update the branch and the change request follows.
You can also close a change request to discard it without merging, and reopen one later if you change your mind.
Before you merge
The change request shows a merge preview so you know what will happen. If the branch has drifted from the default branch, resolve any conflicts on the branch first (have the agent do it in a session), then merge cleanly.
Merging is the only path to your default branch. Sessions, branches, and sandboxes are all upstream of this gate — so review is where you stay in control, no matter how many agents are running.
Why it works this way
Every session runs on its own branch, so any number of agents can work at once without stepping on each other. Each one lands through its own change request, reviewed independently. The result is a clean, auditable history: every change in your project traces back to a session and a merge you approved.
Related: Running a session · Change requests concept.