How a Coding Agent Reads a Kane CLI Run: NDJSON in Action

The Setup: One Command, Two Runs

The first run checks a live page and saves a value the agent needs later. The objective is plain English, and --agent --headless switches the output to NDJSON with no browser window.

kane-cli run "go to https://www.testmuai.com/kane-cli/, assert the main heading mentions Kane CLI, store the main heading text as 'headline'" \
  --agent --headless --timeout 300 > run.ndjson

The second run used the same command shape against a demo store that did not answer from the test machine. Nothing about the command changed. Only the outcome did, which is the case an agent has to handle well.

The Stream as It Arrives

Here is the passing run as it streamed, with the timestamps and process fields kept as Kane CLI printed them. Housekeeping lines about recording and coverage are left out.

{"type": "stream_start", "cli_version": "0.10.0", "surface": "run", "pid": 8420, "v": 1, "ts": "2026-10-30T18:02:16.994Z"}
{"type": "bifurcation", "flows": ["Navigate to https://www.testmuai.com/kane-cli/ then assert the main heading mentions Kane CLI\nGet the main heading text and save as {{headline}}."], "count": 1, "v": 1, "ts": "2026-10-30T18:02:30.924Z"}
{"step": 2, "status": "running", "remark": "Step 1", "v": 1, "ts": "2026-10-30T18:02:33.482Z"}
{"step": 2, "status": "done", "remark": "navigate: Navigate to https://www.testmuai.com/kane-cli/", "v": 1, "ts": "2026-10-30T18:02:33.485Z"}
{"step": 3, "status": "running", "remark": "Step 2", "v": 1, "ts": "2026-10-30T18:02:36.032Z"}
{"step": 3, "status": "done", "remark": "analyze: the main heading text is saved as {{headline}}", "v": 1, "ts": "2026-10-30T18:02:50.238Z"}
{"step": 4, "status": "running", "remark": "Step 3", "v": 1, "ts": "2026-10-30T18:02:51.232Z"}
{"step": 4, "status": "done", "remark": "assert: the main heading mentions Kane CLI", "v": 1, "ts": "2026-10-30T18:02:51.236Z"}
{"type": "run_end", "status": "passed", ...}

An agent can use the middle lines for progress. Each step line says which step is running or done, and its remark names the action: navigate, analyze, assert. A coding agent can echo these to its user while it waits, so a 30-second check never looks frozen. The bifurcation line shows how Kane CLI split the objective into flows before it started; here there was one flow.

The agent does not need to understand every line to act. The decision lives in the last one.

Run One: A Pass the Agent Can Use

The passing run exited with code 0 and ended with this line, shown here with the fields an agent reads:

{
  "type": "run_end",
  "status": "passed",
  "one_liner": "verified the Kane CLI heading on testmuai.com",
  "final_state": {
    "url": "https://www.testmuai.com/kane-cli/",
    "headline": "Kane CLI\nTesting Agent for\nDEVS"
  },
  "duration": 27.1
}

Two fields carry the result. status says passed, and final_state holds the headline the objective asked Kane CLI to store, ready for the agent's next step. A script pulls it out with one command:

tail -1 run.ndjson | jq -r '.final_state.headline'

For a coding agent, this is the green light. The change it was asked to verify renders on a real page, and it has the value to prove it.

Note: Want your coding agent to verify its own work this way? Start free. Try Kane CLI

Run Two: A Failure That Explains Itself

The second run could not reach the demo store from the test machine. Kane CLI exited with code 3 and ended with this line:

{
  "type": "run_end",
  "status": "failed",
  "one_liner": "The browser could not reach the site, and the follow-up page capture timed out.",
  "summary": "The initial request to the ecommerce site timed out before the page could load. ... Check network egress, proxy/DNS routing, and target-site availability, then rerun once the site is reachable.\nevidence: network_failure: GET https://ecommerce-playground.lambdatest.io/ -> None FAILED (net::ERR_CONNECTION_TIMED_OUT)",
  "final_state": {},
  "duration": 138.1,
  "reason_code": "infra_error.screenshot_failed"
}

A pass/fail flag alone would tell the agent to go fix something. This line tells it more. The exit code is 3, not 1, so no assertion failed. The one_liner says the site was unreachable, the summary carries the network evidence, and reason_code starts with infra_error. The right move is to retry later or report a connectivity problem, not to rewrite working code.

That difference matters most for coding agents, which act on whatever they are told. An agent that treats every red result as a bug will happily edit code to fix a network outage.

Turning the Stream Into a Decision

Put together, a caller needs only the exit code and the last line. The script below is the whole decision, and the same logic works inside a CI step or a coding agent's tool call:

kane-cli run "$OBJECTIVE" --agent --headless --timeout 300 > run.ndjson
code=$?
result=$(tail -1 run.ndjson)

case "$code" in
  0) echo "PASS: $(echo "$result" | jq -r '.one_liner')" ;;
  1) echo "BUG: $(echo "$result" | jq -r '.one_liner')"; exit 1 ;;
  *) echo "COULD NOT CHECK: $(echo "$result" | jq -r '.one_liner')"; exit 2 ;;
esac

The exit code meanings come from the Kane CLI modes documentation: 0 passed, 1 an assertion failed, 2 an error such as auth or Chrome, and 3 a timeout or cancellation. The one_liner turns each case into a sentence a human can read in a Slack alert or a pull request comment.

The same pattern scales from one check to a pipeline. To run it on every pull request, follow the guide to connect Kane CLI to GitHub Actions, and to run it on a schedule against production, see synthetic monitoring with Kane CLI.

Note: Want to see the event types in code? Open the repo. Open the repo

Testing from the terminal? Kane CLI by TestMu AI lets SDETs and developers plan, write, run and debug tests from the command line.

To run your first test, start free, or

book a demo

for a full walkthrough of the product.