Review results

Start with the run's outcome: what it completed, which checks ran, and which results were published. Then inspect the changes against the original request.

Read the outcome before the diff

A summary explains what the run reports doing. Private artifacts are files retained by Devboxes. Published results point to work in an external system, such as a pull request. Publication failures explain where delivery did not complete.

A run can finish its execution without producing the result you expected. A published pull request can still need changes. Use the outcome and evidence together rather than treating a success label as code approval.

Inspect the changes

Open the session's Review tab or the published pull request. Confirm the repository and branch, review the changed files, and look for missing tests or unrelated edits. Check whether the reported test commands actually completed.

Review data may still be arriving while a run is active. An empty or unavailable review capture is not evidence that no files changed; check the transcript and repository result.

Give feedback the agent can act on

Anchor feedback to a file or line when useful. Explain the defect and the expected behavior, rather than only saying the implementation is wrong.

The empty-state check runs after the network request.
Return the validation error before making the request, and add a test that
asserts no request is sent for an empty display name.

Use a follow-up in the same session when the work is related. The organization or project can configure review continuation: mention-only reacts to @devboxes; automatic mode can start a follow-up when feedback arrives. Review that policy before posting test comments in a live repository.

Decide what to merge

Use your team's repository checks and approval process. Confirm the current commit, not just an earlier reviewed version. Stopping a run, changing a review policy, or deleting a credential is not a rollback of published code.