Review branch history and add repositories

Use Git/Review to inspect earlier commits, compare a branch's changes, or bring another repository into the project. Open it from the desktop titlebar after selecting a thread on the devbox you want to inspect, or opening the Template box page. If that machine is sleeping, wake it from the machine status control in the titlebar. Git/Review reviews and shares work; to create or switch branches, ask your agent or run Git yourself in Terminal.

Inspect history

1. Check the repository selector, especially if the project has several repositories.
2. Open the selection dropdown near the top of Git/Review; its label shows the current selection, such as Uncommitted changes. From its history list, choose a branch, remote branch, commit, or commit range. Shortcuts select common ranges: All of <your branch> shows the branch's changes since it left the default branch, and Since origin/<branch> shows commits you haven't pushed.
3. Expand a changed file to read its diff.

A single commit shows its message, author, committer, and parents. A range shows the combined changes; in the pane beside the thread, it also lists the commits, and each one expands to its full message.

The same dropdown returns you to working-tree changes (edits on the machine) and staged changes (edits selected for the next commit). The available actions follow that selection: Uncommitted changes offers New commit, while a committed selection such as All of <your branch> or Since origin/main can offer Create PR. See Commit, push, and open a pull request when you're ready to save or share the work.

Binary, generated, oversized, and conflict diffs may not display; inspect those files in Files or Terminal. Conflict diffs are read-only — resolve the conflicts in the files on the machine before continuing the Git operation.

Switch between uncommitted changes and a commit from the repository's history. Select the image to enlarge it.

Work with several repositories

Each repository has its own branches, history, and staged changes, and Git/Review operates on one selected repository at a time. Check the selector before staging, committing, or publishing so the action lands in the repository you mean.

Supported layouts keep either one repository at the project root or several repositories in direct child folders — folders directly inside the project directory. Files can still browse outside the selected repository. Nested repositories, submodules, overlapping layouts, and additional worktrees of the same repository are not added by Review new repositories, described below.

Add a repository for future devboxes

A repository added on the Template box becomes part of what future devboxes start with, while a repository you review on a devbox stays on that devbox. Use the Template box when the whole project should receive it.

Add from GitHub is available when the project already keeps repositories in direct child folders and uses automatic GitHub HTTPS access. In a Team Template member project, tracked repositories come from the Team Template, and a team admin needs to change that shared starting environment.

1. Open Template box and expand Repositories, below Snapshots.
2. Choose Add from GitHub and select the repositories to add. A project supports up to 20 associated GitHub repositories, and repositories already in the project aren't selectable.
3. Review the destination folders and access. If prompted, reconnect GitHub or grant the missing repository or Workflows permission, then refresh.
4. Continue with the addition. boxes.dev will clone the repositories into direct child folders, configure automatic GitHub access, and save a new Template box snapshot. If a folder name is already taken, the clone's folder name will include the repository owner.

Future devboxes will receive the repositories from that snapshot; existing devboxes won't change. If the new repositories need install or startup commands, choose Review Startup Script to edit Devbox lifecycle → New devbox defaults → Startup Script yourself — boxes.dev won't edit it for you. See Startup, teardown, and maintenance for how that script runs.

Neither Add from GitHub nor the manual review below converts a project whose root is itself a repository into a multi-repository layout. A repository cloned inside that root will be nested and won't be added by the review. For an SSH or non-GitHub project that keeps repositories in direct child folders, clone the new repository manually and review it as described below.

Review a repository you cloned manually

1. Clone the repository into a direct child folder of the project directory on the machine where you want to use it.
2. Open Git/Review on that machine and choose Review new repositories.
3. Select the repositories to include, up to 20 per review. A GitHub HTTPS repository can offer Configure automatic GitHub HTTPS access; clear it to add the repository without changing its credentials. SSH and other remotes keep their existing credentials.
4. Confirm the review.

On the Template box, the review will save a new snapshot so future devboxes inherit the repository. On a devbox, it updates only that devbox's repository list: nothing is copied to the Template box or to other devboxes, and no snapshot is taken. An older machine may show Rescan instead until it updates.

Recover an interrupted addition or missing access

Fix GitHub access repairs a repository that has lost its automatic access configuration. Select the repository in Git/Review, or open the Template box's Repositories card, and choose Fix GitHub access when it's offered.

Closing the Add from GitHub progress dialog won't cancel the work. If the addition is interrupted, reopen it from the Repositories card's attention message and choose Continue. If only the final snapshot failed, retry it from the progress view; the retry won't repeat the completed repository work.