The dashboard

Runs & Ship

Ship is the signature click: it starts a Run, and a Fixback-hosted coding agent takes the Issue — the whole Evidence bundle in context — and drives it toward a merged PR, as far as your trust policy allows. This page is what a Run is and how it behaves.

Ship it

An Issue's primary action is a split button: Ship it on one side, Hand off on the other. Ship needs three things in place:

a connected repository on the Project;
an Agent connection — who pays and which model the Run uses;
a passed environment check for the Project's current run config.

The Ship dialog shows the connection it will use and the Run's stopping point, then hands the Issue to a Run. A Public-tier Issue must be Promoted by a Member before it can Ship at all — see Trust & automation.

What a Run does

A Run is one execution attempt against an Issue. It moves through a fixed sequence of stages, streaming a live agent log the whole way:

Stage	What happens
`clone`	The sandbox clones your repository at the connected branch.
`locate`	The agent reads the Brief, the Evidence and the code-area pointer to find the code to change.
`implement`	It edits the workspace — the only writable place in the sandbox.
`tests`	Your project's own install and test commands run against the change.
`pr`	The typed change set becomes a branch and a pull request, through the pre-push gate.
`merge`	On green, and only if the stopping point allows it, the PR merges.

Every Run runs in a fresh, isolated sandbox that executes your project's own scripts — so the protections that matter are enforced by the sandbox boundary and the pre-push gate, not by asking the agent nicely. That is its own page: Built-in protections.

Active and waiting

The Runs page splits what is happening now from what is stopped for a person:

Active — a Run that is queued, provisioning or running. It is doing work right now, and you can cancel it.
Waiting — a Run that opened its PR and is holding at a review gate. It can sit for days and is never counted as active.

Each Run carries a human key — RUN-1, per workspace — a change summary, its PR link, the model it used, and its cost. What a Run reports — branch → PR → merge → deploy → the Issue closing — is the same Linked work and Activity a handed-off agent feeds; a Run is just a second producer into it, so the return path closes the Issue either way.

The stopping point

A Run's stopping point is how far the pipeline goes before it stops for a human, and it comes from the reporter's tier:

Reporter tier	Default stopping point
Internal	`merge` — open the PR and merge on green.
Invited	`pr_drafted` — open the PR and wait for a Member to Approve & merge.
Public	`pr_drafted`, and only once Promoted.

The Ship dialog can tighten the point for one Run — from merge down to pr_drafted — but never loosen it. A Run at pr_drafted sits waiting at the gate until a Member Approves & merges.

The environment check

Before a Project's first hosted Ship, Fixback runs an environment check: a check Run that clones, installs and runs your tests in the sandbox with no agent, streamed on the Runs page like any Run. On green it stamps the Project as ready.

Retries

An Issue can have several Runs. A retry after a failure is a new Run, not a re-execution of the old one — each Run keeps its own log, change set and conclusion, so the history of what was attempted stays intact.

Hosted and dispatch

Everything above describes a hosted Run — the agent runs in a Fixback sandbox on an Agent connection you configure. There is a second plane, dispatch, where the agent runs on your own account and Fixback observes only the resulting PR through the return path:

Open in Claude Code (cloud) opens the composer pre-filled with the Issue — a Handoff marker, not a Run.
A Routine-fired dispatch does create a Run on your subscription, shown on the Runs page with an Open-session and an Abandon action.