Kane CLI Testing Agent for DEVS

Kane CLI is an AI-driven testing tool for you and your agents. You describe what you want in natural language, for example "log in as an admin, open the billing page, and verify the plan shows Enterprise", and Kane CLI drives a real Chrome browser to get it done. No selectors, no brittle scripts, no custom Domain Specific Language. It's built for developers, QA engineers, and AI coding agents that need to navigate, test, or extract data from web apps.

Three audiences:

• Developers and QA engineers who want to write end-to-end tests in natural language instead of maintaining Playwright or Selenium scripts. The wider AI QA picture covers where this sits next to authoring, coverage, and orchestration.
• AI coding agents (Claude Code, Cursor, Codex, Gemini, custom agents) that need a reliable way to drive a browser and ensure validation for applications as part of a larger workflow.
• Platform and DevOps teams that want browser-based checks running in CI without a codebase to maintain.

KaneAI is the web-based test authoring and management platform. Kane CLI is the terminal-native companion with the same automation engine, accessible from your shell, your CI pipeline, or an AI agent. Runs triggered from the CLI are uploaded to the KaneAI dashboard so you get the replay, step-by-step logs, and test case management alongside your web-authored tests.

Those are frameworks you write and maintain by hand. The real cost is the maintenance, and it grows with the app. Kane CLI generates fresh test plans, runs them against your live app or API, keeps every passing test so coverage compounds, and repairs its own tests when the UI drifts. No scripts to write, no selectors to babysit, no suite quietly rotting between releases.

The CLI itself is free to install and use. Execution uses your TestMu AI account. Local runs are free, and cloud runs on the TestMu AI grid are billed against your TestMu AI plan the same way any other KaneAI session is.

Yes. Kane CLI authenticates against TestMu AI so that runs, screenshots, and test cases can sync with the KaneAI dashboard and your team's workspace. If you don't have an account yet, you can sign up for free at testmuai.com. The free tier is enough to try the CLI end to end.

The fastest way is npm:

npm install -g @testmuai/kane-cli

After install, verify with kane-cli --version and sign in with kane-cli login (opens a browser) or kane-cli setup --auth-method basic --username <user> --access-key <key> for headless environments.

Yes. Use kane-cli setup --auth-method basic with your TestMu AI credentials, pass --headless and --timeout on each run, and use --agent if you want structured NDJSON output you can parse in a post-step. The CLI exits with code 0 on pass, 1 on fail, 2 on setup/auth errors, and 3 on timeout, so your pipeline can gate on it cleanly.

Run npm install -g @testmuai/kane-cli@latest. Check your installed version any time with kane-cli --version, and see the latest release at https://github.com/LambdaTest/kane-cli/releases.

Yes. Use {{variable}} syntax in your objective and supply values via --variables, a --variables-file, or JSON files in .testmuai/variables/. Mark sensitive values with "secret": true and Kane CLI will mask them in logs and push them through TestMu AI's secrets API instead of storing them in the clear.

Yes. Pass --headless and Chrome runs invisibly. Combine with --timeout to cap runs in CI. If you need to debug a failure visually, re-run without --headless locally and watch the browser.

The CLI itself runs one objective per invocation, but the agent mode is designed to be fanned out. Spawn multiple kane-cli run --agent --headless processes from your test runner, CI matrix, or AI agent, and aggregate the NDJSON results. Each run gets its own isolated Chrome session.

Healing has two tiers, and the difference between them is the whole answer.

Step-heal is the common case. Replay can't resolve one step's target (an id was regenerated, an element moved, the markup got refactored), so kane re-finds that one element by what it is rather than where it sat. The step's place in the flow is unchanged and every other step is untouched. It's a local repair, it's most of what happens in practice, and it's measured: pointed at a page engineered to regenerate its element ids on every single load, a saved check re-found its target and passed every time. No edit, no engineer, no LLM spend.

Flow-heal only runs when a step can't be healed at all, when the step as written is no longer possible because the route itself changed. Only then does anything re-reason the path to the objective.

The risk lives entirely in that second tier, and two things bound it. It is a last resort rather than a default, so the cheap local repair is exhausted first. And it operates on the path, never on the acceptance criteria. It can re-find a route to the same stated outcome, but it has no authority to redefine what "passed" means. A test quietly adapting itself into testing something else would require the agent to be able to edit the criteria. It can't. A wrong total doesn't get healed into green; it gets reported as a bug.

The honest boundary: all of this is strongest when an element's addressing changes and its meaning doesn't. Semantic drift is harder. Think of a button that keeps its label but now routes somewhere else. There we would rather fail loudly than adapt, and that's a deliberate choice, not a solved problem.

A pass is the full set of acceptance criteria for that scenario being satisfied. Not one assertion, not a vibe, not the model's own account of what happened. You write the criteria. The system's job is to establish whether they hold.

That's also the line between reasoning and verification: reasoning owns the path, verification owns the verdict. The model never gets a vote on whether the test passed, which is the one design decision everything else in the product hangs off.

A verdict you can't reconstruct is just AI-generated confidence with extra steps, so this is the part we care most about.

Every run emits self-contained test run evidence in a format we call .evidence. Drop that file into evidence.lambdatest.com and you get the entire run back: every step, screenshots, network logs, console logs, and terminal output. If the run failed, you also get the bug we reported, with its category and the verdict behind it.

So the honest answer is that an engineer shouldn't have to reconstruct anything. The run hands them the evidence and invites them to check our work. If someone can't get from a verdict back to the specific thing that produced it, that's a bug in us, not a limitation of the approach.

The question is worth splitting first, because a "flaky test" is usually a bad locator, a static wait, or a race condition being blamed on the app. Two of those three are removed by construction: there's no locator to rot, because you never wrote one, and no hand-tuned wait to guess wrong.

For what's left, kane-cli has a bug-detection pass that tries to classify what it's looking at and returns a verdict with a confidence signal rather than a bare red. It is genuinely partial. Nondeterministic application state is hard, and we'd rather tell you that than claim we've closed it.

It has to, and the reason is cost shape. Replay is cached and deterministic, so the per-run cost doesn't scale with how much code an agent generated this week.

What scales is the number of intents a human is willing to state, which is the right bottleneck, because that's the part that should stay human.

Kane CLI uses Chromium (Google Chrome) locally. However, once the test case is authored, you can execute the test case on any browser/OS combination on HyperExecute or locally.

Yes, that's one of the main reasons it exists. Every run supports an --agent flag that switches output to structured NDJSON, so an AI agent can parse results, read screenshots on failure, and decide what to do next. There's also a ready-made Kane CLI Skill for Claude Code that handles setup, objective writing, and failure diagnosis out of the box.

Yes. Each run is uploaded to your KaneAI workspace. You'll get a test_url in the output that links to the replay, step-by-step logs, screenshots, and AI reasoning. From there you can manage it like any other test case, add it to a suite, or share it with your team.

Yes, Kane CLI is open to community contributions on documentation and skills. Docs contributions include fixes to the README, guides, and examples. Skill contributions improve the instructions AI coding agents (Claude Code, Codex CLI, the npm skill package) use when they drive Kane CLI, adding examples, covering new commands, or correcting inaccuracies. Full details and the code of conduct live in CONTRIBUTING.md.

Open a blank GitHub issue describing what you'd like to contribute and the maintainers will point you in the right direction. Bug reports and feature requests go through the same tracker. Both humans and AI agents are welcome to file them.

Yes. Kane CLI is featured and listed on several third-party sites, including Aback Launch, Product Hunt, AlternativeTo, SourceForge, and G2.

All issues and feature requests are tracked publicly at https://github.com/LambdaTest/kane-cli/issues, and the Skills added for Kane CLI already include instructions for coding agents to file bugs automatically. For manual reports, use the repo's templates and include your kane-cli --version, operating system, the exact command you ran, and (if available) the run_summary.json and failing screenshot from the session directory.

• Docs: https://www.testmuai.com/support/docs/kane-cli-introduction/
• Support: support@testmuai.com for account and billing questions
• Issues and feature requests: https://github.com/LambdaTest/kane-cli/issues