Following runs
A run takes minutes, sometimes hours, and you don't have to sit in the terminal that started it. Three things show you what it is doing: awf run's own progress, awf runs for where the run stands, and awf logs for what it did, event by event, its agents' own work included. All of it is read from the run's record, so any terminal, or another agent, can follow a run it didn't start. The examples follow check-readme, the one-stage workflow on How it works.
awf runs # the runs here, newest first
awf runs check-readme/{id} # one run: its stages, its agents, what to run next
awf logs check-readme/{id} --follow # each event as it comes, until the run endsWhat awf run shows
On a terminal, awf run keeps one block redrawn in place: the run's name, its current stage and how long it has taken; a row per stage, ✓ once it succeeded, ↺ when it was reused, and the current one with each agent working in it, its model, placement and time; and the stages an earlier attempt recorded, still to come, dimmed. A line from wf.log or a message between agents prints above the block. When the run ends, the block keeps each stage's row with what its agents used, and a closing block says how the run ended and where its record is.
Anywhere else, such as piped to a file or run from an agent's shell, it writes one line per change, timed from the start, after a first line that names the run:
awf: check-readme/20261101-0930-a1b2 started · watch: awf logs check-readme/20261101-0930-a1b2
[0:00] ▶ stage review
[0:00] ▶ reviewer · sonnet
[0:41] ✓ reviewer · 41s
[0:41] ✓ stage review · 41sAll of that goes to standard error. Standard output carries only the result: what the workflow's present makes of it or, for a workflow without present such as check-readme, the run's whole record from out.json. So awf run check-readme.ts > result.json keeps the record, with the verdict as its value, and none of the progress.
| Flag | What it changes |
|---|---|
--json | Standard output gets the run's whole record, its out.json, even when the workflow has present. A run that doesn't complete prints its record too, once its agents have started. Questions for a person are not asked at the terminal. |
--quiet | Leaves out the progress and the wf.log lines, for a run a scheduler or supervisor starts, which reads anything on standard error as a problem. A run that completes or parks writes nothing there; one that fails, stops or is cancelled writes only how it ended. A question for a person still prints how to answer it, and awf logs reads everything left out. |
--no-watch | Leaves out the tab a docker sandbox's panes get in the run's workspace (Sandboxes). |
When a run has TUI agents, awf run prints once, as the first one opens, a line starting agents with the Herdr session the agents are in and the herdr session attach command that shows them. Run it in another terminal to watch the agents work, or to type into one. Harnesses covers panes.
awf runs: where a run stands
$ awf runs
check-readme/20261101-0930-a1b2 running 11-01 09:30 14s
check-readme/20261031-1712-0c4e completed 10-31 17:12 41s $0.03
check-readme/20261031-1650-9d1f stopped 10-31 16:50 2m 05s $0.06A row per run, newest first: its name, its status, when it started, how long it took, and an estimate at list prices where its agents reported usage. It lists 20; --limit {n} lists another number. A run of a workflow with events that is waiting shows what it waits for. A run an earlier awf made, before its record had a format, is listed unreadable, and nothing else of it is read (Data).
Name a run to see it in depth: its attempts, the stages of the last one, and each agent's state, turns and last activity. Under it is what to run next.
$ awf runs check-readme/20261101-0930-a1b2
check-readme/20261101-0930-a1b2 running stage review 14s
stage review running 12s
reviewer working turn 1 9s last: tool Bash grep -n "awf " README.md (09:30:09)
next: awf logs check-readme/20261101-0930-a1b2 --after c2.WzQsMix7ImExIjozMTg3fV0 --wait 90sA running run ends with a next: line, the awf logs command that waits for what comes next. One that ended says where its record is, and why when it didn't complete. A failed one adds a see: line, the logs of the agent that failed, and one that can go on adds its continue: command. A run whose process is gone without ending, as after a crash, is interrupted. Runs says what each status means and how a continue goes on.
awf logs: what a run did
$ awf logs check-readme/20261101-0930-a1b2
check-readme/20261101-0930-a1b2 running stage review
@e1 09:30:02 attempt 1 started
@e2 09:30:02 review stage started
@e3 09:30:02 reviewer opened claude
@e4 09:30:05 review reviewer turn started
@a1.4b1 09:30:06 review reviewer prompt 412 chars
@a1.9e2 09:30:09 review reviewer tool Bash grep -n "awf " README.md
next: awf logs check-readme/20261101-0930-a1b2 --after c2.WzQsMix7ImExIjozMTg3fV0 --wait 90sawf logs merges two sources by time: the run's own events (stages, turns, messages, tool calls, wf.log lines) and what each agent did in its harness, read from the harness's own session files: its prompts, its tool calls and their results, its messages. Without a run named it reads the newest run here, and notes any other that is running. It shows the last 40 events.
Each line starts with a handle: @e… for the run's events, @r… for a fork's session or one an agent moved to, from run.jsonl, and @a… for an agent's activity; --json has every agent's first session too. A line is cut short; awf logs {run} @{handle} --full prints it whole.
awf logs {run} --agent reviewer # one agent, and the messages to and from it
awf logs {run} --stage review # one stage
awf logs {run} @a1.9e2 --full # one event's whole text
awf logs {run} --limit 200 # more than the last 40--full masks common credential shapes, but the text is what the agent saw and wrote: treat it as you would its session.
Every answer ends with what to run next. While the run goes, that is a next: command that gets only what is new: --after {cursor} reads from where the last answer stopped, oldest first, and --wait {duration}, such as 90s and up to 5m, waits for the first new event when there is none yet, answering once it comes or the time is up. Once the run is over the last line says so: run ended: …, or run interrupted · continue: …. --follow instead prints each event as it comes and returns when the run ends.
Following a run from another agent
A coding session can start a run and keep working, or follow a run someone else started. It needs no tool beyond its shell:
- Start it as a long command, in the background if your harness has one. Its stderr is not a terminal, so the first line is
awf: {workflow}/{id} started · watch: awf logs {workflow}/{id}. That line's prefix is stable to match on. - Name the run by that reference in every later command, never by "the newest": another run may start beside it.
- Read with the
watch:command, then run each answer'snext:exactly, and stop at an answer with nonext:, which endsrun endedorrun interrupted. Each call returns within its--wait, so it never holds a tool call for the length of the run, as--followwould. - Read the result from the finished
awf run's output, or withawf runs {workflow}/{id}.
For a program, --json on awf runs and awf logs prints one document, versioned with "v". awf logs --json gives the events with their text, a cursor, and next as an argument list while there is more; awf runs {run} --json, "v": 2, gives the status, attempts, stages and agents, and continue where a run can go on; awf runs lists the states it uses. --follow doesn't take --json; page with --after and --wait. Runs has awf run's exit codes.
To hand the session itself to the run, so that it becomes one of the run's agents, use awf run --here: Calling session.
awf open: ask an agent why
awf open review/r7 fixer # a copy of fixer's session, in its harness's TUI
awf open review/r7 fixer -p "why did you skip migrate.ts?" # one question to a copy, the answer printed
awf open review/r7 fixer --no-fork # fixer's session itselfawf open copies an agent's latest session, without asking the model, and opens the copy in its harness's TUI where the agent worked: its working directory, its skills, its sandbox, on its model and effort. You ask what it read, why it did what it did, and it answers with its whole context. The run and the agent's session are untouched, so it works on a finished run, a parked one and a live one, except for a sandboxed agent: its sandbox is reopened, so that is refused, live or opened, while an attempt runs or another awf open has it open. The harness asks before it runs a command, as it would for you, except where it never asks: pi; a cursor agent's chat, which keeps the run's "Run Everything"; and codex in a sandbox, where its own sandbox is off and the agent's sandbox is the boundary.
As the harness exits, awf prints again:, the command that opens the same copy, --session and its id. -p asks one question headless and prints the answer; it runs as the agent's turns did, without prompts. Headless claude is billed per token, so -p on a claude agent is refused unless it ran with metered: true.
--no-fork opens the session itself, so what you say stays with the agent: the next attempt resumes it with your turns in it, and awf logs shows them. It is refused while an attempt runs. While it is open, no attempt starts and a second --no-fork is refused; an event that would start or continue the run waits, awf emit says opened, and once the harness exits a run of a workflow with events is woken for it.
Catches
- A copy is yours. awf keeps no record of it: it lives in the agent's harness home until that goes. Note its
again:line to come back to it. - They look where the run is kept.
awf runsandawf logsread.awf/runsunder the current directory. A run started with--cwdor--run-rootis read with the same flag; the commands awf prints repeat it for you. - "The newest" moves.
awf logswithout a run reads whichever run started last here, which may not be yours once another starts beside it. Name the run when it matters. - The estimate is not a bill. It prices the tokens the agents reported at list prices; Cost says what it does and doesn't mean.