Runs
A run is one execution of a pipeline for one issue. Runs are started by triggers or by hand, queue up behind Max concurrent runs, and move through the statuses queued → preparing → running (↔ awaiting approval) → succeeded / failed / cancelled.
The Runs page
Section titled “The Runs page”Sidebar → Runs. The table shows every run, newest first:
| Column | Content |
|---|---|
| Run | #number |
| Task | Issue key and title (or the pipeline name), with the pipeline, branch and any links found below |
| Status | Status pill |
| Progress | One dot per step, coloured by step status |
| Source | What started it: manual, linear, jira, github, schedule or webhook |
| Duration | Elapsed time (live while running) |
| Cost | Total reported cost, or — |
| Started | How long ago |
Filters across the top:
- All, Active (queued, preparing, running), Needs approval, Succeeded, Failed (failed and cancelled), with counts;
- All pipelines / one pipeline;
- a search box (Search issue, branch, #number) matching the issue key, title, pipeline name, run number and branch.
Click a row to open the run.
Starting a run manually
Section titled “Starting a run manually”New run (Dashboard, Runs page, sidebar, ⌘N, the tray menu, or Run on a pipeline) opens Start a run:
| Field | Notes |
|---|---|
| Pipeline | Lists every pipeline with its step count and project. |
| Task title | Required. Becomes {{issue.title}}. |
| Issue key | Optional, e.g. ENG-123. Used for branch names. If empty, TASK-<n> is used. |
| Issue URL | Optional link back to the tracker. |
| Description | Becomes {{issue.description}}. |
vars.<name> |
One field per pipeline (and project) variable, with its default as the placeholder. Filled-in values override the defaults for this run only. |
Start run (or ⌘↵) validates the pipeline and its workspace first. If something’s missing you get an error such as Can't start: Workspace: choose the local git repository, … and no run is created.
The run view
Section titled “The run view”Header
Section titled “Header”#number, the issue key and title (or pipeline name), the status pill, and the run’s error in red if it failed.- Issue ↗: opens the issue in the tracker (when the run has an issue URL).
- One button per link found in step outputs, e.g. PR #57 or Preview. Jimothy recognises GitHub pull request URLs, GitLab merge requests, Bitbucket pull requests and
*.vercel.apppreviews. - Open workspace in editor (
</>icon): triescode, thencursor, and falls back to opening the folder in your file manager. - Reveal workspace folder (folder icon): opens the workspace in your file manager.
- Cancel while the run is active; Retry and Delete run once it has finished.
The workspace buttons are hidden when you use Jimothy from another device through Remote access.
Metadata strip
Section titled “Metadata strip”Pipeline (link to the editor), Trigger (what started it), Branch (with a copy button), Started, Duration, Cost and Tokens (12.4k in · 3.1k out; input includes cache reads). Graph collapses or expands the graph.
Live graph
Section titled “Live graph”The pipeline graph shows every step as a node with its type, status icon, harness and model (or the shell command, or Human approval), and duration. Edges light up as work flows; feedback loops are drawn as amber arcs under the graph, and a node shows ↺ with the loop count once it has been re-run. Click a node to select that step.
Approval banners
Section titled “Approval banners”Each step waiting for approval shows a banner above the step list. See Approvals.
Step list
Section titled “Step list”The left column lists Setup & run log (workspace preparation, git operations and the run summary) followed by every step with its status, harness and model (or shell / approval), attempt count, loop count and duration.
When you open a run, Jimothy selects the step that most needs attention: the one awaiting approval, else the running one, else the failed one, else the last succeeded one.
Step detail
Section titled “Step detail”The step header shows the status, name, type, harness, model and cost. When a step has more than one attempt, a dropdown switches between them (Attempt 2 (loop 1) · succeeded). Failed steps show their error in a red box.
Tabs:
| Tab | Content |
|---|---|
| Logs | The attempt’s log, streaming live (see below). |
| Output | The step’s final output. Agent output is rendered as Markdown; shell output as plain text; for approvals, the approver’s comment. |
| Prompt / Command / Message | What the step actually ran, after template rendering: the prompt for agent steps, the command for shell steps, the message for approvals. Before the step runs, the template is shown instead. |
| Details | Duration, tokens, cost, the harness session id (Claude Code, Codex, Pi), the approval decision (who, when, comment), and the attempts table (#, loop, status, started, duration, exit code). Click an attempt to open its logs. |
The log viewer streams each line with a timestamp and an icon for its kind:
| Icon | Kind | Examples |
|---|---|---|
· |
system | $ claude -p …, Retry 1/1, Feedback loop iteration 1 |
◆ |
assistant | the agent’s messages |
∴ |
thinking | reasoning blocks |
⚙ |
tool | Bash: npm test, Edit: src/api.ts, $ pytest |
↳ |
tool result | command output, file contents (clipped) |
✓ |
result | success · 12 turns · $0.4213 · 81234 in / 2210 out tokens |
› |
stdout | plain-text harness output, shell output |
! |
stderr | stderr lines |
✗ |
error | failures, tool errors, verdict failures |
Toolbar: Filter logs (text search), a Thinking checkbox to hide reasoning, a live badge while the attempt runs, the line count, Copy logs, and Follow output (auto-scroll; scrolling up pauses it, scrolling to the bottom resumes).
What you get depends on the harness’s output format: Claude Code, Codex and Pi show structured tool calls and thinking; plain-text harnesses show raw stdout. See Output formats.
Cancel
Section titled “Cancel”Cancel on an active run:
- a queued run is cancelled immediately;
- running steps are stopped by killing the whole process tree (
SIGTERM, thenSIGKILLafter 5 seconds), so agents and anything they spawned stop; - approval gates stop waiting;
- remaining steps are marked cancelled and the run ends cancelled.
The workspace and branch are left as they were. A cancelled triggered run counts as a failure for write-back.
Once a run has finished (succeeded, failed or cancelled):
| Button | Re-runs |
|---|---|
| Retry (header) | Every step that didn’t succeed, plus everything downstream of it. Succeeded steps keep their output. |
| Retry from here (step header) | The selected step and everything downstream of it, even if they succeeded. |
Retries reuse the run’s workspace and branch if the folder still exists, so work done so far is kept. They use the pipeline’s current definition, so you can fix a prompt or command in the editor and retry the same run. Steps you added since get a fresh entry; history is kept for existing steps. Feedback-loop counters start again from zero.
Delete
Section titled “Delete”Delete run removes the run and its logs. You can only delete a finished run (Cancel the run before deleting it). The workspace folder is kept; remove it yourself or enable Delete a run’s workspace after it succeeds in Settings.
Where run data lives
Section titled “Where run data lives”Each run has its own folder, runs/<run-id>/, in the data folder: run.json plus one JSONL log per step attempt. See Data & security.