For managers
Submit a scoped task, follow its progress, and review the result with your team.
Devboxes gives your team a shared record of coding-agent work. Use it to delegate a specific repository change and follow the result through technical review. A session keeps the request, the agent's work, and related follow-up runs together.
You need an owner or admin role to start runs or send follow-up instructions from the dashboard or CLI. Members can follow sessions. Your job title does not determine your Devboxes role. Ask an owner or admin to complete the quickstart before the team's first task.
Submit one task and follow the result
Suppose a CSV export splits a customer name containing a comma into two columns. Create a GitHub issue with an example, the expected output, and a requirement to preserve the existing column order. Ask a developer to add the command that tests the export and agree who will review the change.
After the project is configured, an owner or admin can start the work:
- Open Sessions and choose Dispatch run. Select the project, an available model, and Implement GitHub Issue.
- Enter the issue URL and acceptance criteria. End the task input with
ISSUE_URL=<issue-url>andDESTINATION_BRANCH=<base-branch>, replacing both placeholders. Choose Dispatch run. - Open the resulting session. Read the run status, then check Transcript for questions and the result. The Review tab shows the changes available for inspection.
For the complete input example, use Run your first task. Ask the person who dispatched the work to share its session link with the reviewer. An ordinary session link requires access to the same Devboxes organization.
Decide what needs attention
A queued run is waiting to start. Ask the person responsible for setup to check the project's image, runner, and model access before submitting the same task again.
When a run needs input, read the request in Transcript. Ask an owner or admin to supply the missing fact or decision. For a failed run, read the error and ask a developer to determine whether the task, configuration, or implementation needs a change.
When execution finishes, compare the reported outcome with the issue. For the CSV task, ask the reviewer to confirm that values containing commas stay in one field, the column order is unchanged, and the export tests passed. The reviewer should inspect the diff and any failed or skipped checks before recommending acceptance.
A finished run can leave a pull request that still needs review. Follow your team's GitHub approval and merge process. Devboxes execution status does not replace that decision.
Assign responsibility
| Decision | Suggested owner |
|---|---|
| Task scope and acceptance criteria | The person requesting the work. |
| Repository, runner, and model setup | An organization owner or admin with the relevant technical access. |
| Technical review and follow-up instructions | A developer familiar with the repository. Sending follow-up instructions also requires an owner or admin role. |
| Approval and merge | The people required by your team's repository policy. |
These responsibilities are separate from organization permissions. Review credentials and security before giving tasks access to sensitive repositories or systems.
Evaluate a trial
For each task, record whether the requested change was accepted, how much review it needed, and what had to be redone. Use those observations to choose the next tasks. Run counts alone do not show whether the team produced useful changes.
Once the team has a process worth repeating, review a blueprint with the developers who will use it. A blueprint records the steps future runs should follow.