Inspect a run in flight

While Vibestrate is working you can watch it. The dashboard is the primary place; the terminal and the files on disk are the automation paths to the same record.

vibe ui opens Mission Control; vibe run "..." --ui opens it alongside a run you are starting. New run in the dashboard launches in the background and drops you on the run screen.

The main thing to watch is the Live timeline: one row per step in the flow, each carrying

• its status,
• the role and profile in the seat - which agent is in the chair, on which settings,
• the elapsed time, ticking up while it works,
• a live tail of what the model is writing.

Expand a row for that seat’s prompt, its full transcript (text, thinking and tool activity as they stream), and its response.

Around the timeline:

• Live metrics - token usage and cost, as the provider reports them.
• Changed files - what the run has touched so far. Click one to see its diff or full contents, read from the run’s worktree.
• Live execution - a raw console over every recorded provider stream.
• Workspace - the worktree path and branch, with a copyable cd.
• Artifacts - the inspector tab holding the changed-file list and the diff viewer together.

The Source page’s Changes tab reads the same diff against main, for the project and for any run’s worktree.

vibe opens the interactive shell; page 5 is Runs. The scheduler queue sits at its top, active runs show the current agent, MCP servers and skills, and finished runs say why they ended. tab switches the inspector section, / filters the events tail, and p / r / a pause, resume or abort the selected run.

A plain vibe run narrates itself: one line per flow step as it starts, warnings as they come up, and a final block with the run’s status, the review and verification decisions, and the paths to its artifacts, worktree and branch.

That is a summary, not the model’s own output. To read what a provider actually wrote, tail its stream:

vibe logs <runId> --follow

Streams are recorded per step in the run’s own streams/ folder, so vibe logs works on a finished run too. Without --follow it prints the newest stream and exits, and --stream picks a specific one by name.

Everything is recorded at .vibestrate/runs/<runId>/:

.vibestrate/runs/bold-lovelace/
  state.json            current status, transitions
  events.ndjson         every event, append-only
  actions.ndjson        brokered action + verdict
  runtime-metrics.json  tokens, durations, costs
  flow.json             the resolved flow snapshot
  participants.json     role + profile per seat
  streams/              raw provider output
  artifacts/flows/<step-id>/

Each flow step gets its own folder under that last path, holding what it was asked and what it answered:

artifacts/flows/<step-id>/
  prompt.md                the prompt for this step
  output.md                the provider's response
  validation-results.json  commands run + exit codes
  validation/              one file per command
    <n>-<command>.stdout.txt
    <n>-<command>.stderr.txt

Token, duration and cost figures are recorded where the provider reports them, and the two validation entries only appear for a step that validates.

Run ids are docker-style pairs like bold-lovelace, not sequential numbers; runs are listed in the order you started them, not by id.

Every line in events.ndjson is one JSON object: a timestamp, an event type, a human message, sometimes a data payload. One filter pulls out the whole status history:

jq -r 'select(.type=="state.changed").message' \
  .vibestrate/runs/bold-lovelace/events.ndjson

created → planning
planning → planned
...
verifying → merge_ready

Swap the type for review.decision, verification.decision or action.denied to answer a different question off the same file.

Watching a run go the wrong way does not leave you a choice between abort and hope.

Open the run and the control centre carries a Steer box, directly above the transcript you have been reading. Write what should change, choose which step reads it - Whichever step runs next, or a named step still to come - and press Queue note. The box says how many notes are waiting, and tells you plainly when no process is running the run, because a note queued on a crashed run would never be read.

The note lands at the next step boundary, not the instant you send it. That is deliberate: a code-writing seat holds an open worktree, and cutting into it between two writes would leave half-written files behind. The cost is at most one step of latency.

Steering only appends to the run’s state - no provider call, no shell command, no write into the worktree - so it is safe to send at any moment, including while a step is mid-flight. Twenty notes may wait at once; past that the run has to read some before you add more.

From a terminal:

vibe steer <runId> "use the existing retry helper, do not write a new one"
vibe steer <runId> --step review "check error handling specifically"

Request changes on an approval is a different move, not this one: it re-runs the stage you are standing at, where a steer feeds a step that has not started yet.

Open any run from the Runs page and the Inspect section’s Replay tab walks it start to finish. It works on a run that finished long ago, one synced from another machine, one you never watched live.

Replay is read-only wherever you open it: it reads what the run recorded and changes nothing.

From a terminal: vibe replay <runId>.

• Run state - what the status field means.
• Debug a failed run.