Commit, push, and open a pull request

When the changes on your devbox look right, use Git/Review in the desktop app to save them and share them with your team: stage the changes that belong together, commit them to the repository on the devbox, then push the branch or open a GitHub pull request. A commit alone stays on the devbox — push anything you want to keep before destroying the machine.

Git/Review shows the changed lines before you stage or commit them. Select the image to enlarge it.

Review and commit

1. Select the thread on the devbox where you worked. If the devbox is sleeping, wake it from the machine status control in the titlebar, then open Git/Review.
2. Check the repository selector if the project has several repositories. In the selection dropdown near the top, select Uncommitted changes and read the diffs. Click a file's path in a diff header to open that file in Files.
3. Choose New commit. Select files under Unstaged Changes and choose Stage to include them in the commit. Where the diff offers it, you can stage selected lines or groups of changes (hunks) instead of whole files.
4. Check Staged Changes. Use Unstage to leave a change out of this commit without discarding the edit.
5. Write a commit message and choose Commit, or press Cmd+Enter (Ctrl+Enter on Windows and Linux).

Commit stays disabled until at least one file is staged, the message isn't empty, there are no unresolved conflicts, and no other Git action is in progress. Your draft message is kept on this laptop, separately for each machine and repository, while you work.

To discard edits instead of committing them, select unstaged changes and choose Revert. Check the selected files or lines before confirming: reverting will remove those edits.

Amend Last Commit, when offered, changes the most recent commit instead of creating a new one. Check whether you've already shared that commit before rewriting it.

Stage the files you want to include, review the diff, and write a commit message. Select the image to enlarge it.

Open a pull request

You can open a PR from a feature branch, or straight from work committed on the default branch. In the second case, Create PR will first move your commits to a new branch: the preparation step lists the exact commands, which move the committed work, restore the local default branch to its tracked remote version, and publish the new branch. Your uncommitted changes will move with the working tree, but they stay out of the pull request until committed and pushed — commit first when they belong in it. The flow will not push the remote default branch.

1. Open the selection dropdown near the top of Git/Review — its label shows the current selection, such as Uncommitted changes — and choose your commits: All of <your branch> on a feature branch, or Since origin/main (named for your default branch) when the commits are still on the default branch.
2. Choose Create PR for the GitHub repository. If the dialog shows the preparation step, read the proposed branch and the listed commands, then choose Prepare pull request. Preparation fetches the remote's current state; it will not pull, merge, or rebase your branch.
3. Check the source branch, destination, title, and description. Open Options to choose reviewers or make a draft PR.
4. Choose Create pull request.

If Create PR is missing, check the selection dropdown — it needs committed changes, such as All of <your branch> or Since origin/main — and that the repository is on GitHub. Choose Connect GitHub if it appears, or see GitHub access for connection and permission problems.

Push or publish a branch

Use Push to share commits without opening a pull request; Publish does the same for a branch that doesn't yet track a remote branch. Both stay available whenever they're valid, as the prominent main button or under More actions.

The push dialog leads with the commits about to be pushed, newest first, and the exact remote destination. The list is informational and never blocks the push, but read both before confirming, especially when you're pushing directly to the default branch — that action's label names the commit count and destination.

For a branch that already tracks a remote branch, pushing runs as Pull & push. The dialog states whether the remote branch has commits you don't have, with the pull strategy on the same line: Repository setting follows your Git configuration, Rebase reapplies your commits after the remote changes, and Merge merges the remote changes into your branch. Choose Pull & push; boxes.dev will pull first and push only if the pull succeeds. Expand Details for the exact commands and progress — it opens on its own while a step runs or after a failure.

If the pull stops on conflicts, nothing is pushed. Git/Review names the active merge or rebase and the conflicted files; resolve, continue, or abort the operation in Terminal, then return to review. boxes.dev will not stash your changes, resolve conflicts, or force-push for you.

Neither push nor publish includes uncommitted changes: those files stay only on the devbox, and the dialog says how many stay behind. Uncommitted edits can also make the pull stop if they conflict with incoming changes. For a branch that doesn't track a remote branch yet, Publish prepares by fetching and checking the destination, without pulling, then asks you to confirm.

Update and merge an existing pull request

Git/Review names the next action in the selected pull request's header, based on the PR's state:

• Fix checks prepares a prompt about the failing checks in the composer.
• Address feedback imports the PR's unresolved GitHub review comments into the Code review attachment.
• Mark ready marks a draft PR ready for review.
• Push to update PR sends a committed revision through the same pull-first push dialog.
• Merge opens the merge dialog; confirm after checking the PR.

Fix checks and Address feedback don't start the agent on their own: inspect what they prepared in the composer, then choose Send. Use View PR #N to open the pull request in your browser.

Right after you switch repositories or branches, pull request actions may wait briefly while GitHub state updates; if they stay unavailable, wake the machine and refresh Git/Review.

After a PR merges, boxes.dev may offer Destroy + archive in the thread when the devbox is clean and still on the merged PR's last commit. Destroying the devbox will delete its local files, so save any other useful files before confirming. Files in shared project storage will remain.

Automate PR follow-ups

To have the selected agent respond to PR problems on its own, open the actions menu in the selected pull request's header, choose Automate follow-ups, and select Failed checks, Bot review feedback, or both. Turning this on authorizes the agent to act without you: when a selected event arrives, boxes.dev will wake that exact machine and ask the selected agent thread to follow up, and the agent may edit files, run tests, commit, and push to the pull request branch. If it can't identify a safe fix, it will stop and explain why instead.

An automatic follow-up will not merge or force-push the pull request, delete its branch, rerun workflows, or answer or resolve review comments. Bot feedback covers only reviews and comments that GitHub identifies as bot-authored, so comments from people won't start a follow-up. Only one agent per boxes.dev account can handle a PR's follow-ups at a time; turning them on from another agent shows the current one and asks you to move the job.

Follow-ups need GitHub CLI in devboxes access on that machine, and the boxes.dev GitHub App needs access to the repository so GitHub can deliver the selected events. A personal GitHub connection alone isn't enough; see GitHub access.

Use Edit follow-ups to change the events, resume, or turn the feature off. boxes.dev will pause follow-ups after three attempts without a healthy PR until you review the recent work and resume them, and also when the repository, branch, agent, or CLI access stops being valid or follow-ups repeatedly fail to start. They end when the PR closes or merges. The manual Fix checks and Address feedback actions remain available either way.

When the PR merges, boxes.dev will send the saved agent thread a final notice so it knows the work landed. The notice may wake the machine and will wait behind an active turn; it will not ask the agent to edit files or switch branches. Paused follow-ups still receive this notice while their original thread remains available. Turning follow-ups off disables it, and archived or deleted threads won't receive it. Closing a PR without merging ends follow-ups without a notice.

Choose Git defaults and commit attribution

Open Project settings → Git to choose whether Create PR or direct Push/Publish appears as the prominent main action. The preference changes ordering only — both workflows remain available whenever they're valid — and applies to the project's Template box and all of its devboxes.

Add thread links to commits, in the same section, connects commits to the conversations that produced them; it is off by default. When it's on, a commit you make in Git/Review will include the selected thread's permanent link as a commit trailer when the link is available, and a commit made with no thread selected — for example from the Template box page — will have no link. Codex and Claude agents started in boxes.dev will also try to add the link to their own commits; their commits still succeed when it's unavailable.

Amending a commit won't add its link twice. The setting doesn't change commits made in Terminal or outside boxes.dev, and opening a linked thread requires the appropriate team access.

Commit author identity, commit signing, and GitHub authentication are separate settings. Check GitHub access if the push identity or permissions need attention.