Review

Review is where the agent's work shows up as a diff. It is three things side by side: a dropdown that decides which changes you are looking at, a list of the files in them, and the diff of whichever file is selected.

Opening it

Click the sidebar button at the far top right, or press Cmd+Shift+R (macOS) / Ctrl+Shift+R (Windows, Linux), and the tab is there for every project — a folder with no version control included.

Two more controls sit in the same header. The file-tree button at the far left folds the file list away so the diff gets the whole width, and remembers the choice. The app button at the far right opens the project in your editor; its chevron picks which editor that is.

Which changes

The dropdown at the top of the file list is the important control on this tab, because the same session looks different under each option.

Git changes — everything uncommitted in the working tree, whoever made it. This is the default in a git project, and the one to use when you are about to commit.

Branch changes — your branch against the default branch, so it includes work you have already committed. It is offered only when you are actually on a branch other than the default one; on the default branch there would be nothing to compare against and the option is left out rather than shown empty.

Last turn changes — only the files the agent's most recent turn touched. This is the one to use while you are working: it answers "what did that reply just do", without the rest of your uncommitted work drowning it.

In a project with no git repository, Last turn changes is the only option, and the tab offers to fix that — see When there is nothing to show.

The header beside the dropdown carries the running totals for the current scope, added lines then removed.

The file list

Files are grouped into a tree by directory. Added and deleted files are marked; modified ones are not, because in a list of changes every row is a change and the marker would be on almost all of them.

Filter files narrows the list as you type. While a filter is active the tree flattens into a plain list of matches — nesting is not much help when you have already named what you want — and ↑ ↓ move through it with Enter to open the highlighted file. The filter is deliberately forgotten when you leave: a remembered one would quietly hide files the next time you opened the tab and look like a panel with changes missing.

The list can be dragged wider or narrower between 200 and 480 pixels, and both the width and whether it is folded away are remembered across launches.

The diff

Split is the default — old on the left, new on the right — and the toolbar's other option is Unified, one column with the removals and additions interleaved. The choice is remembered.

Beside it, a second pair of buttons controls how much of the file you see. Hide non-diff lines is the default and shows the changed hunks with a little context; Show all lines expands the whole file around them. Also remembered.

< and > step to the previous and next file without touching the list, so you can read straight through a change with one hand. They are ignored while you are typing in the filter or in a comment. With the file list folded away the toolbar shows your position — 3/11 — since the list is no longer there to show it for you.

Files with more than 500 changed lines on either side are rendered as you scroll rather than all at once. There is nothing to click and nothing is truncated; only the rendering is deferred.

Commenting on lines

Selecting a line, or dragging across a range, offers a comment box on that selection. What you write there does not go anywhere on its own — it is attached to your next message, carrying the file and the line range with it, and the composer's placeholder changes to Summarize comments… to say so. This is how you send "this bit is wrong, and here is why" without describing where "this bit" is.

Typing @ inside a comment mentions files, the same way it does in the composer.

A comment's ⋯ menu edits or deletes it before you send. Comments belong to the session and survive a reload, so you can leave a few on a long diff, come back, and still send them together. Sending clears them; walking back through prompt history to a message that had comments brings them back with it.

When it updates

The list follows the files, not the conversation. Saving a file — by the agent, by your editor, by a git checkout in a terminal — updates the changes within a moment, and writes inside .git itself are ignored so routine git bookkeeping does not churn the list. The scope is also refreshed whenever the session goes idle, which is what makes the diff complete the instant a long turn finishes.

When there is nothing to show

An empty scope says No file changes yet. It means what it says — that scope really is empty — so if you expected changes, check the dropdown before anything else. Last turn changes is empty whenever the last reply only read and searched without writing anything, which is the usual reason a session that has clearly been busy shows an empty Review tab.

A project with no git repository is a different message: No tracked changes, with a Create Git repository button. Pressing it runs the equivalent of git init in the project, and the Git changes and Branch changes options appear once it has.

Opening a file

Review shows diffs, not files. To open the file itself, use the + beside the tabs: it opens an Open file browser in the panel with the cursor already in its filter. Cmd+P / Ctrl+P gets to the same place through a search dialog instead, which is the faster route when you know the path.

Either way the file becomes its own tab in the panel, alongside Review and Context, and you can select lines and comment there too.