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

Ship it is one of the three actions on an Issue's Hand off button — in its menu, or on the blue button itself when it is the default handoff action. 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.

A hosted Run is metered by its sandbox minutes. If the workspace has reached its on-demand cap, Ship, Retry and the environment check are refused with New hosted Runs are paused (spend cap), naming the Owners who can lift it; a Run already running finishes, and dispatch Runs are never paused.

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 is never Shipped automatically — only on a Member's own Ship click — and stops at a drafted PR by default; see Trust & automation.

It gives no dollar or minute estimate. Its Effort line is a hint in words, gauged by analysis from the Evidence — Likely a contained change, Likely a contained fix or Likely needs investigation (which adds that the Run may stop at the gate without a fix) — with a one-line reason, or Not enough evidence to gauge effort. It is not a measurement: what bounds a Run is its wall-clock and turn caps.

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. While a Run is active its cost counts up as it goes ($0.04 so far · estimated); once it finishes it shows the recorded figure with its basis ($0.42 estimated) and a token line — input, cached, cache-write and output. A Run with no measured cost shows none. The Runs page follows the same Project scope as the Issues queue, so the Projects you picked there are the ones listed here. 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` — capped org-wide; wait for a Member to Approve & merge.

The Ship dialog can tighten the point for one Run — from merge down to pr_drafted — but never loosen it, except that a Public Run may be loosened to merge with an explicit confirm. 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.

The pull request

A Run's PR is written for the people who review it: a lead-in linking the Issue, Why this change (an excerpt of the Brief, marked as Fixback's summary of the reporter's evidence), What changed (the agent's own note, or the changed files when it wrote none), Tests, and a Generated with Fixback footer naming the agent and linking the Run and the Issue. It closes with the linkage trailer, so the return path links it.

If someone closes the PR without merging it, the Run ends as PR closed — a neutral outcome, not a failure — with nothing merged and Retry run beside it.

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.