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

Hover over or click the PR indicator in the conversation header to see the pull request's title, repository, branch, checks, review, and last refresh. Threads using the same checkout share its branch and PR. If the checkout has multiple pull requests, the panel lists each one with its own links. PRs merged or closed before a devbox was created stay in Git/Review and do not appear in its thread indicators. PRs completed during work on the devbox still show their merged or closed status.

Choose Fix CI & apply feedback to prepare the available CI fixes and review feedback together. Choose Fix CI or Apply review feedback to handle just one, or Resolve conflicts when the branch conflicts with its base branch; an option is unavailable when there is no work of that kind. Review the prepared prompt and Code review attachment, then choose Send to start the agent. Choose Open PR in Git/Review in the same panel to inspect the pull request.

The collapsed Git/Review header shows checks and review separately. Choose Details to expand it. No checks reported means GitHub hasn't reported checks for that PR; it doesn't mean the checks passed.

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

• Resolve conflicts prepares a prompt asking the agent to bring the base branch into the PR's branch the way your repository does.
• 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.

Resolve conflicts, 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

Automatic follow-ups let an agent keep its pull request moving without you starting each step. When a selected event happens, boxes.dev will wake the agent's machine and ask that agent thread to follow up. You can choose any of these events:

• Failed checks: a check on the PR fails.
• Review feedback from people: someone GitHub lists as the repository's owner, an organization member, or a collaborator leaves a review or comment.
• Bot review feedback: an account that GitHub identifies as a bot leaves a review or comment.
• Merge conflicts: the PR's branch conflicts with its base branch.

To turn follow-ups on for one PR, open the actions menu in the selected pull request's header, choose Automate follow-ups, and select the events. The project's default follow-up events will already be selected. Turning this on authorizes the agent to act without you: it may edit files, run tests, commit, and push to the pull request branch when your instructions and the repository's rules allow pushing. The agent will check the PR's current state on GitHub first. If it can't identify a safe fix, it will stop and explain why, and if it isn't making progress, it will also turn follow-ups off. An agent can also turn follow-ups on when you ask it to. If the project doesn't turn them on automatically, an agent may offer to after it opens a pull request.

To turn follow-ups on for new PRs automatically, open Project settings → Git and turn on Automate follow-ups on new pull requests. It's off by default. While it's on, boxes.dev will turn on the project's default follow-up events when you choose Create PR in Git/Review with a thread selected, or when an agent runs gh pr create on one of the project's devboxes. The thread that opened the PR will handle its follow-ups. The setting doesn't cover PRs opened another way, such as on GitHub or with gh pr create in your own terminal, or a branch that already had an open PR. If you turn a PR's follow-ups off, they stay off.

To choose the project's default follow-up events, open Project settings → Git and select them under Default follow-up events. All four are selected unless you change them. They'll apply when follow-ups start without anyone picking events, either from the setting above or when an agent turns follow-ups on without choosing events. PRs that already have follow-ups will keep their own events.

An automatic follow-up will not merge the PR, delete its branch, or rerun workflows. The agent will force-push only after rebasing to resolve merge conflicts, and then in a way that refuses to overwrite commits someone else pushed. It will reply to or resolve review conversations only when your instructions or the project's agent guidance tell it to.

Review feedback from people includes reviews that request changes or include a comment, inline review comments, and comments in the PR's conversation. Approvals without a comment, edits, and deletions won't start a follow-up. Neither will your own reviews and comments, because agents act on GitHub as you; message the agent in its thread instead. The filter uses each author's relationship to the repository as GitHub reports it, and it doesn't check whether they can push to the repository.

Bot review feedback includes a bot's reviews, inline review comments, and comments in the PR's conversation, along with edits to them. A bot's approval won't start a follow-up, even when it has a comment.

Review bots often post a status comment, a review, and inline comments over a minute or two, and people often leave several comments in a row. boxes.dev will wait until three minutes pass without new review feedback from either, or ten minutes after the first, and then send it all to the agent in one follow-up. If failed checks or a merge conflict need a follow-up sooner, it will include the waiting feedback.

If a Codex agent is working when an event happens, its follow-up will wait for the current turn to finish. Later events will join a waiting follow-up that already covers those kinds, even if a different kind of follow-up was queued more recently. The agent will check the PR's current state when it starts.

GitHub doesn't announce new merge conflicts, so boxes.dev will check the PR about ten minutes after its base branch changes, or later if the agent was asked about a conflict within the past hour. If there's a conflict, the agent will bring in the base branch the way your repository does: it rebases if the project's agent instructions or the repository's pull.rebase Git setting say to, and merges otherwise. Updating the branch can dismiss approvals in some repositories. Conflicts alone will wake the agent at most once an hour, and if it can't resolve a conflict, boxes.dev won't ask again until the branch changes.

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. While that agent's thread is still available, other agents move follow-ups to their own thread only when you ask.

Follow-ups need GitHub CLI 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. Follow-ups work only for pull requests into the repository's default branch.

Connected personal access will take priority for the gh commands agents run. To let an agent start or rerun a workflow with your account's permissions, connect optional personal access in Integrations → GitHub or run gh auth login and approve the GitHub code. Automatic follow-ups will still receive their events through the GitHub App.

Use Edit follow-ups to change the events, resume, or turn follow-ups off. The dialog notes when the project setting or an agent turned them on. boxes.dev will pause follow-ups when the repository or branch changes, including when the PR is retargeted to another base branch, when CLI access stops working, or when follow-ups repeatedly fail to start. Renaming or transferring the repository on GitHub won't pause them, even if you also update the checkout's remote to the new name. Archiving the agent's thread or destroying its devbox, whether you do it or an automation's cleanup does, pauses its follow-ups until you turn them on from another thread or from the restored one; deleting the thread turns them off. They end when the PR closes or merges. The manual Fix checks, Address feedback, and Resolve conflicts 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.

When a PR closes or merges, boxes.dev will also try to cancel its waiting automatic repairs. A repair already being sent to the agent or running may finish. Your queued messages and follow-ups for other PRs will stay in place.

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.

Automate follow-ups on new pull requests, also off by default, turns on automatic follow-ups for pull requests opened from the project's threads.

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