How to Troubleshoot Kane CLI Issues

This page lists common problems with Kane CLI, what causes them, and how to fix them. If you are new to the CLI, start with Installation and Getting Started. For setup questions, see Configuration and Authentication.

Log Locations

Before diagnosing, know where to look:

Log	Path
Session log (session narrative)	`~/.testmuai/kaneai/sessions/<session-id>/tui.log`
Evidence pack (step logs, screenshots, console and network logs, failure records)	`~/.testmuai/kaneai/sessions/<session-id>/evidence/<execution_id>.evidence`
All sessions	`~/.testmuai/kaneai/sessions/`

Run logs are stored only in the evidence pack. A .evidence file is a plain zip, so you can unzip it and read the logs directly, even without the viewer. See Inside the pack for its layout. In Agent Mode, the run_end event includes session_dir, the directory that holds the session log and the sealed evidence pack. The event also includes run_dir, a legacy per-run path. Step logs and screenshots are inside the evidence pack.

Chrome Issues

”Chrome failed to launch”

Kane CLI manages a Chrome process for you and connects to it over the Chrome DevTools Protocol (CDP). If launch fails, the most likely causes are:

Chrome is not installed in any of the locations Kane CLI searches. On macOS it looks under /Applications/Google Chrome.app and equivalent user paths; on Linux it looks for google-chrome, google-chrome-stable, chromium, and similar binaries; on Windows it looks under Program Files\Google\Chrome\Application\chrome.exe and the user’s AppData\Local.
Chrome is installed in a non-standard location Kane CLI does not search. Point it at the binary with KANE_CLI_CHROME_PATH=/path/to/chrome.
All CDP ports from 9222 to 9230 are in use. Kane CLI looks for a free port in this nine-port range. If every port is busy, you see an error like All CDP ports 9222-9230 are in use. Close other Chrome instances.
Another running Chrome holds the profile lock. If a separate Chrome instance already uses the same user-data directory, the new instance can fail to start cleanly.
Chrome is slow to become reachable. On cold or overloaded machines, often CI runners, Chrome can launch but not respond over the DevTools Protocol within the timeout for each attempt (default 30s). Kane CLI retries the launch automatically (twice by default). If Chrome stays slow, raise the timeout or the number of retries.

Fix:

Install Google Chrome (or Chromium / Chrome for Testing) from the official source for your platform. If it is installed but in an unusual path, set KANE_CLI_CHROME_PATH to the binary.
Quit any extra Chrome processes that may be using ports 9222 to 9230. On macOS or Linux, you can list them with:
lsof -i :9222-9230
Pick a different Chrome user-data directory, or quit the Chrome instance currently using it. See Chrome Management for how Kane CLI chooses and configures the profile.
If you only need to connect to your own already-running Chrome, start it with --remote-debugging-port=9222 and pass --cdp-endpoint to kane-cli run:
kane-cli run "..." --cdp-endpoint http://127.0.0.1:9222
On a slow runner, raise the readiness timeout with KANE_CLI_CDP_TIMEOUT_MS (milliseconds, default 30000), the retry count with KANE_CLI_CDP_RETRIES (default 2; 0 means a single attempt), or both. A missing or invalid binary fails immediately and is not retried, so retries help only when Chrome is temporarily slow to start. See Chrome environment variables.

”CDP endpoint not reachable”

Cause: Using --cdp-endpoint but Chrome is not running on that port. Fix: Remove --cdp-endpoint and let Kane CLI manage Chrome automatically. Or start Chrome with remote debugging before running:

google-chrome --remote-debugging-port=9222 &
kane-cli run "..." --cdp-endpoint http://localhost:9222

Chrome opens then closes immediately

Cause: Another Kane CLI instance is already running and holds the Chrome profile lock. Fix: Check for running kane-cli processes:

ps aux | grep kane-cli

Kill any existing processes, then retry.

Authentication Issues

”Authentication failed” (exit code 2)

Cause: Expired tokens or incorrect credentials. This means Kane CLI could not produce a valid auth token for the configured environment. Fix for interactive use:

Re-run the login flow:
kane-cli login
Confirm which profile, environment, and token state are active:
kane-cli whoami
If the token is missing or expired and refresh did not succeed, log in again.

Fix for CI / non-interactive use: Kane CLI can authenticate with username and access key instead of OAuth. Verify both values against the credentials shown in your dashboard, then pass them on the command line:

kane-cli run "<objective>" \
  --username "YOUR_LT_USERNAME" \
  --access-key "YOUR_LT_ACCESS_KEY"

If they still do not work, regenerate the access key in the dashboard and retry.

”Not configured” on first run

Cause: No profile exists yet. Fix: Run the login flow:

kane-cli login --username "YOUR_LT_USERNAME" --access-key "YOUR_LT_ACCESS_KEY"

Get credentials from the dashboard > Credentials.

Basic auth not working

Cause: Wrong username or access key. Fix: Verify your credentials on the dashboard. Username and access key are case-sensitive. Make sure you’re using the access key (not the password). If kane-cli login exits immediately with Login failed — fetch failed, or a NODE_DEBUG=undici trace shows an OpenSSL error code like UNABLE_TO_GET_ISSUER_CERT_LOCALLY, Kane CLI could not validate the TLS certificate of an auth or upload endpoint. Browsers and curl on the same machine usually still work, because the problem is specific to Node’s default trust store. Node ships with its own bundled Mozilla CA list and does not read the operating-system keychain by default. Corporate endpoint security software (EDR), a TLS-inspecting proxy (Zscaler, Netskope, GlobalProtect), or a similar tool may sign traffic with a root certificate that exists only in the OS keychain. Node cannot validate that certificate. Browsers and curl succeed because they trust the keychain directly. Try these fixes in order:

Tell Node to trust the system keychain. Use this built-in environment variable, available in Node 22.19+ and 24.6+:
export NODE_USE_SYSTEM_CA=1 kane-cli login
See the Node docs. On macOS, this reads the default and system keychains with the same trust policy your browser uses, so any root certificate that works for curl and your browser also works for Kane CLI.
Point Node at a specific CA bundle. If your IT or security team can give you the corporate CA file, use the standard Node environment variable:
export NODE_EXTRA_CA_CERTS=/path/to/corp-ca.pem kane-cli login
This is also the fallback for Node versions older than 22.19, where NODE_USE_SYSTEM_CA is unavailable.
Make the setting permanent by adding the export line to your shell profile (~/.zshrc, ~/.bashrc, or equivalent) so every new terminal picks it up. Otherwise, the variable applies only to the shell where you ran export.

Runner: “[SSL: CERTIFICATE_VERIFY_FAILED]” behind a TLS-inspecting proxy

If kane-cli login succeeds but a run fails mid-execution with an error like:

[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate in certificate chain

the failure is in the bundled v16-runner, not in Node. The runner is a standalone Python binary (built with Nuitka) with certifi’s cacert.pem built in. It does not use the Windows, macOS, or Linux system trust store, and the Node fixes above (NODE_USE_SYSTEM_CA, NODE_EXTRA_CA_CERTS) do not affect it. On a corporate network with a TLS-inspecting proxy (Netskope, Zscaler, GlobalProtect, and similar), the proxy decrypts and re-encrypts HTTPS with its own self-signed root CA. That root is in your OS keychain but not in certifi’s bundle, so the runner’s TLS handshake fails. On a home network, no proxy intercepts the traffic, so the chain validates against certifi and the same command works. To fix it, give the runner a CA bundle that includes the corporate root:

Get the corporate root CA from IT. On Windows you can export it yourself: open certmgr.msc → Trusted Root Certification Authorities → Certificates, find the proxy’s CA (often named after Netskope / Zscaler / your company), right-click → All Tasks → Export, choose Base-64 encoded X.509 (.cer).
Concatenate it with certifi’s cacert.pem into a single PEM file. On Windows, for example, save the combined file as C:\certs\corp-bundle.pem.
Point the runner at the combined bundle with SSL_CERT_FILE. Windows (persists across new terminals):
setx SSL_CERT_FILE "C:\certs\corp-bundle.pem"
Restart the terminal after setx. Only new shells pick up the variable. macOS / Linux:
export SSL_CERT_FILE=/path/to/corp-bundle.pem
Add the export line to ~/.zshrc / ~/.bashrc to persist it.

If kane-cli login also fails in your environment, apply the Node fix from the previous section as well. The two environment variables cover two different processes, so you may need both.

Run Issues

”Run timed out” or “max steps exceeded”

A run times out when it reaches its time limit. It ends with a max-steps error when the agent uses up its allowed number of steps before finishing. Cause: The objective is too complex, the page is slow to load, or --max-steps is too low. Fix:

Increase --timeout: --timeout 300
Increase --max-steps: --max-steps 60. The CLI default is 50.
Split the work into smaller objectives. Run several kane-cli run commands one after another, each focused on one task. The session keeps the same browser between runs, so state carries over.
Make the objective more specific. Vague objectives often make the agent wander, so state the outcome you want and any required values up front.

Agent repeats the same action

Cause: The agent is stuck in a loop because the page did not change after the action. Fix: Rephrase the objective to be more explicit. Add an assertion after the action to confirm state changed:

"click the Save button, assert the page shows 'Saved successfully'"

“Variables not resolving”: `{{key}}` appears literally

A run warns before it starts when an authored step references a {{name}} that has no value. The warning lists each variable, the file waiting for its value (or Not in any variables file), and the step that uses it. The run then goes ahead and types the name as written. Read the warning first. It tells you whether to fill an existing key or add a new one, and in which file. See Before a run. If a {{my_var}} placeholder appears literally in a browser action, one of three things is true:

The warning above named it and nothing set it. Fill in the value and run again. (A replay step resolves from its recording and from Test Manager instead.)
The reference is escaped. \{{my_var}} is typed as is on purpose, for pages where the braces are real text.
The variable file is not loaded at all. Check the three points below.

Cause: The variable file is not loaded, the JSON format is wrong, or the variable key name is wrong. Fix:

JSON syntax. Variable files are JSON. A missing comma or unquoted key causes the file to be skipped silently.
File location. Variable files must be in one of the directories Kane CLI scans. Confirm yours is in the right place. See loading order for the exact precedence.
Inline test. Bypass file loading entirely by passing the variable on the command line:
kane-cli run "log in as {{user}}" \ --variables '{"user":{"value":"alice"}}'
If the inline form works, the issue is with file loading, not the variable itself.

Assertions fail even though the page looks correct

Cause: The assertion wording does not match what is on the page, or there is a timing issue. Fix:

Check the step’s screenshot in the evidence pack to see exactly what the agent saw
Refine the assertion: use assert the page contains (substring) instead of exact text
Add a wait: "wait for the confirmation message to appear, then assert..."

CLI exits with code 2 and no output

If kane-cli run ends with exit status 2 and prints nothing to stdout or stderr after the first startup lines, one of two things is usually the cause:

Authentication or setup is missing. This is the common case on a new machine. Run kane-cli whoami. If it reports “not configured”, run kane-cli login again (or pass --username / --access-key in non-interactive environments). See also “Authentication failed” above.
Kane CLI was installed with an unsupported package manager, most often pnpm. pnpm stores packages in a nested node_modules/.pnpm/ directory, and Kane CLI does not search that layout for its bundled v16-runner binary. The CLI stops before it can print a useful error. Issue #24 tracks this limitation. To work around it, reinstall with one of the supported methods listed in Install with pnpm or yarn.

To see the underlying error instead of a silent exit, run the same command again with KANE_DEV_MODE=1:

KANE_DEV_MODE=1 kane-cli run "<objective>" --agent --headless

In dev mode, setup failures and failures to find the runner print an explanation before the process exits. Use that message to tell which of the two cases applies. Do not leave KANE_DEV_MODE=1 in production scripts.

Upload Issues

”Upload failed” or “Test Manager error”

Cause: Kane CLI uploads run artifacts to Test Manager at the end of the session, and that upload failed. Fix:

Authentication. Check kane-cli whoami and log in again if needed. The Test Manager upload needs a valid token (or basic auth) for the configured environment.
Network connectivity. The upload connects to the control plane and a cloud storage endpoint. Make sure a proxy or firewall is not blocking outbound HTTPS.
Project and folder. If kane-cli config show reports an empty project_id, you do not need to do anything: Kane CLI picks a default project on the first run. To upload to a specific project or folder, set it with kane-cli config project <id> / kane-cli config folder <id> (use kane-cli projects list / kane-cli folders list to find IDs), or pick one in the TUI. If a configured project was deleted or renamed, Kane CLI detects it and picks a default instead. An invalid ID typed by mistake is handled the same way. See Test Manager Integration for the full behavior.

Agent Mode Issues

No NDJSON output / only seeing TUI

Cause: Missing --agent flag. Fix: Add --agent to your command:

kane-cli run "..." --agent --headless

NDJSON parsing fails: `jq` errors or unexpected output

Cause: Stderr is mixed into stdout, or you are parsing events from the middle of the stream. Fix: Redirect stderr and use tail -1 to get only the final run_end event:

kane-cli run "..." --agent 2>/dev/null | tail -1 | jq .

`ask_user` event fires and blocks the run

Cause: The objective needs input from a person, but it is running through an agent. Fix: Rewrite the objective to avoid prompts. For example, instead of “navigate through the sign-up flow”, be explicit:

"click Sign Up, fill email with '{{email}}', fill password with '{{password}}', click Create Account"

Installation Issues

`kane-cli: command not found` after install

Cause: The npm global bin directory is not in your PATH. Fix:

npm config get prefix

# Add to PATH (adjust path based on above output)
export PATH="$(npm config get prefix)/bin:$PATH"

# Make permanent: add to ~/.zshrc or ~/.bashrc
echo 'export PATH="$(npm config get prefix)/bin:$PATH"' >> ~/.zshrc

Installation fails

Cause: Your Node.js version is below 18. Fix: Check your version and upgrade:

node --version   # Must be 18 or higher

Install fails with “sharp: Please add node-addon-api”

Symptom: npm install -g @testmuai/kane-cli fails with sharp: Please add node-addon-api to your dependencies (any Node version, any platform).

sharp is an optional dependency of Kane CLI, so the install succeeds even if sharp fails. Screenshots then upload as PNG instead of WebP (about 30% larger, with no functional impact). Requires Kane CLI 0.3.4 or later. To upgrade, run npm install -g @testmuai/kane-cli@latest.

Cause: sharp provides optional PNG to WebP screenshot compression. When it cannot load its prebuilt binary, it tries to build from source, and that build fails. On macOS, the most common trigger is a system-wide libvips install (often added by brew install appium, imagemagick, or gdal). Fix (most common, macOS):

# Diagnose: a printed version means libvips is the cause
pkg-config --modversion vips-cpp

# Bypass libvips detection. Uninstall first, since npm considers
# kane-cli already installed and will not re-resolve sharp otherwise.
npm uninstall -g @testmuai/kane-cli
SHARP_IGNORE_GLOBAL_LIBVIPS=1 npm install -g @testmuai/kane-cli

# Make it permanent
echo 'export SHARP_IGNORE_GLOBAL_LIBVIPS=1' >> ~/.zshrc && source ~/.zshrc

There are two other triggers:

npm skips optional dependencies. npm config get omit should not contain optional. Clear it with npm config delete omit and reinstall.
A proxy or private registry does not forward the @img scope. Add an @img:registry=https://registry.npmjs.org/ pass-through.

If PNG screenshots are fine for you, no action is needed. For every cause, the step-by-step fixes, and how to verify, see Install fails with “sharp: Please add node-addon-api”.

Mobile Issues

Local mobile runs are supported on macOS Apple Silicon (arm64) only. On other hosts, run mobile suites on the cloud grid with kane-cli testrun run --remote. See Running a Mobile Suite on the Cloud Grid. For any local mobile problem, start with doctor. It prints one line for each required check, with a fix for each one that fails. doctor checks one target at a time, so pass --target:

# iOS Simulator
kane-cli doctor --target simulator              # required checks, each with a fix if it fails
kane-cli doctor --target simulator --install    # install the test tooling Kane CLI manages
kane-cli devices list --target simulator        # the simulators Kane CLI can run against

# Android Emulator
kane-cli doctor --target emulator
kane-cli doctor --target emulator --install
kane-cli devices list --target emulator

The common setup failures for each platform, and their fixes, are listed on the mobile testing page:

Mobile testing common failures

”Update available” Notice

Kane CLI checks the public npm registry for a newer release of @testmuai/kane-cli once every 24 hours. It caches the result locally, so the check never blocks you and fails silently. When a newer version exists, Kane CLI shows an “update available” notice with the current and latest versions and a severity label (major, minor, or patch). The notice is for your information only, and your current version keeps working. To upgrade, follow the steps in Updates.

Debugging a failed run with its evidence pack

Every run seals an evidence pack that holds everything you need to diagnose a failure. In short:

Open the pack: accept the post-run “View evidence in browser?” offer, or run kane-cli evidence serve <pack> and open the printed viewer URL.
Go to the failed step and read its failure record: the error and the page state at the moment of failure.
Check the step’s console and network logs. A 4xx/5xx response or a JS error there usually explains it.
Compare the annotated screenshot (what the agent acted on) against what you expected.

The full walkthrough is in Evidence packs → Debugging a failed run from its pack, and the pack’s file layout is in Inside the pack. Run logs are stored only in the pack. A .evidence file is a plain zip, so you can unzip it and read the logs directly, even without the viewer. If a pack does not open in the viewer, run kane-cli evidence validate <pack>. A truncated or unsealed pack reports as invalid, but the session directory’s tui.log still has the session narrative. For batch runs, testrun members run silently by default. Set KANE_TESTRUN_MEMBER_DEBUG=1 to send each member’s output to stderr, prefixed with [member].

A `--remote` run refused, failed, or came back empty

There are three different situations. Tell them apart by the exit code and by what came back:

Exit 2 and no job link. The remote preflight (the checks before a job is sent to the grid) refused the selection, so nothing was dispatched. The reason is printed with the paths that caused it: the plugin is missing (kane-cli plugin install remote-execution, then kane-cli plugin doctor remote-execution), the selection mixes web and device tests or two mobile platforms (run them as two suites), a device test names a build that is not on this machine or that the cloud cannot take (mobile_app_missing, mobile_app_not_uploadable), the build’s upload from your machine failed (mobile_app_upload_failed), or required recordings are gitignored (gitignored_inputs, un-ignore with !output-*/). --dry-run reproduces the check without creating a job.
Exit 1 with recordings and a pack. The job ran and a member failed. Debug it like a failure on your own machine: output-<stem>/Result.md names the step and reason, and the pack has the screenshots and logs (next section).
A member reported broken with no steps, and nothing was published. Kane CLI on the grid refused before launching. Open the printed job link and read the scenario stage’s log. For mobile members, the usual cause is an APP… id that belongs to a different organisation than the account running the job. Run kane-cli apps list --target <kind> for the active profile to see which app ids that account owns. The members’ session logs are also under ~/.testmuai/kaneai/sessions/remote/<job-id>/.

Full reference: Remote Runs.

testrun says “plan invalid” or skips members

kane-cli testrun run starts only if every selected test passes preflight. Otherwise, it lists each failing test with a reason:

Reason	Meaning	Fix
`missing_meta`	The test has no recorded output directory next to it.	Run it once: `kane-cli testmd run <path>`.
`not_authored`	The test ran but never committed (no test id).	Run it to completion so it commits.
`org_mismatch`	The test belongs to a different organisation than the other members.	Check identities with `kane-cli testmd status <path>`.
`project_mismatch`	The test belongs to a different project than the other members.	Same check; run project-by-project, or re-home the test.

Use kane-cli testrun run --dry-run … to see the full plan and every failing test without running anything. See Batch runs with testrun.

Context sync: Git not found or too old

A GitHub location (kane-cli context sync add, kane-cli context clone, or kane-cli context sync setup) needs Git 2.31 or newer on the machine that runs Kane CLI. Without it the command refuses before touching anything:

$ kane-cli context sync add team git@github.com:example-org/team-context.git
checking team: read access and safe publishing…
error: This location needs Git 2.31 or newer.
next: Install or update Git, then run setup again: https://git-scm.com/downloads

Install Git from the link, or update it (brew install git, apt-get install git, or the Windows installer). Open a new terminal, check that git --version reports 2.31 or newer, and run the same command again. On a CI runner, add a Git install step before Kane CLI. Folder and S3-compatible locations do not need Git at all. See Sharing the context graph.

Context sync: a location cannot be reached or refuses you

Each case below prints its own message:

Nothing answered. The folder does not exist and cannot be created, the host is down, or no repository answered at that address. A private repository you have not been invited to also looks missing:
error: nothing answered at /no/such/parent/team-context: that folder does not exist and cannot be created next: check the path, then run the command again
Check the address (kane-cli context sync list shows what the store has), that the drive is mounted, and that the repository exists and is shared with your account.
The location answered and refused you. The keys, key pair, or account you used does not have read permission:
error: the bucket at https://team-context.s3.eu-west-1.amazonaws.com did not accept origin's access keys, even for reading next: ask the owner of the bucket for access, or bind it again with the right keys: kane-cli context sync add origin <descriptor> --credential-env <VAR>
<descriptor> in that line is the address of the location. Ask the owner for access, or bind the location again under the same name with the right keys. Running kane-cli context sync add on an existing name replaces its keys, but a key pair the location refuses never replaces one that worked. For a GitHub location over HTTPS in CI, check that KANE_SYNC_GIT_TOKEN grants Contents read and write on that repository.
Over SSH. Kane CLI never answers an SSH prompt. A host key this computer has not accepted yet refuses with this computer has not accepted github.com's SSH host key yet: run ssh -T git@github.com once in a terminal and answer yes. A key that is not loaded, or not on the account, refuses with github.com did not accept your SSH key: load it with ssh-add, or ask the repository owner to grant your account access. Over HTTPS without a stored login the message is sign in is needed, or your account has no access to this repository on github.com: sign in through Git with gh auth login --hostname github.com --git-protocol https --web, then gh auth setup-git --hostname github.com, and run the command again.
The connection check could not finish. The server did not complete the concurrent connection check. Its scratch-ref policy may differ from the storage branch. (SYNC_PROBE_INCONCLUSIVE) means the concurrent connection check did not finish. The usual cause is a repository rule that blocks the scratch reference the check pushes under refs/kane/probe/. Nothing was bound. Ask the repository owner to allow that reference, then run the command again.

A location you can read but not write is not refused. It binds as download-only (read-only: this location can be cloned and pulled, never pushed). kane-cli context push to it refuses with SYNC_READ_ONLY. kane-cli context sync refuses with the same code, but only after its pull has landed, so its exit 2 does not mean nothing happened. Use kane-cli context pull to take records from such a location. The two refusals above change nothing in your store.

Context sync: “a rebase is open” and every change is refused

error: a rebase (2026-09-14T10-13-45-679Z-reset) is open with 2 decisions unresolved; this store takes no other change until it is finished — run kane-cli context sync or kane-cli context pull to continue, or kane-cli context sync doctor --abort to close it
next: run kane-cli context sync or kane-cli context pull to continue, or kane-cli context sync doctor --abort to close it

A kane-cli context pull origin --rebase stopped on decisions you have not answered yet, or it was interrupted. Until the rebase is finished, the store accepts changes from the rebase only, just like git in the middle of a rebase.

kane-cli context extract, kane-cli design tests, kane-cli maintain reconcile, kane-cli context ingest, kane-cli context review, kane-cli context name, kane-cli context retire, and kane-cli context revert refuse with the two lines above.
kane-cli context push refuses with the same code (SYNC_REBASE_PENDING) and the same next: line. Its reason names the rebase and says nothing was pushed.
A test run does not refuse, and nothing is lost. Its results are held aside and land on the first run after the rebase closes.

To resolve it:

See what is open: kane-cli context sync status origin lists each decision on one line, and --show <n> prints one saved record in full.
Answer the decisions: in a terminal, kane-cli context sync origin walks you through each decision card. Without a terminal, use kane-cli context sync origin --answer <id>=keep-theirs (or apply-mine), one flag per decision. keep-theirs writes nothing, but it is an explicit choice, not a default: the local change stays unapplied in the backup, and any later record built on it is reviewed again.
Or close the rebase: kane-cli context sync doctor --abort keeps what was already reapplied and leaves the unanswered records in the backup. If the rebase was interrupted before it imported origin’s records, the same command undoes it and puts the store back as it was. Once the import has landed, the rebase can only be finished (SYNC_RESET_IMPORTED): run kane-cli context sync or kane-cli context pull to finish it, then close it if you still want to. kane-cli context sync doctor --export <dir> rebuilds the store as it was before the rebase, as a separate store in <dir>.

Never delete files under .context/ to get past the refusal. See When two people changed the same thing.

Context sync: publication could not be confirmed

A kane-cli context push to a GitHub location can lose the server’s reply after the upload, for example through a dropped connection or a proxy timeout. Because the batch may have landed, Kane CLI does not guess. It refuses with SYNC_PUBLICATION_UNKNOWN (exit 2). Your store is unchanged and nothing needs to be redone. Check connectivity and run the same command again. It reads the location first and reconciles what actually landed. A batch that arrived is recognised as already there and is never published twice, and a batch that did not arrive is published now. Do not run anything else until this command has finished. If a proxy rejects large uploads, KANE_SYNC_GIT_HTTP_POST_BUFFER=33554432 raises Git’s upload buffer for that command. For a very slow link, allow more time with KANE_SYNC_GIT_TRANSFER_TIMEOUT_SECONDS. See Context sync environment variables.

Filing a Bug Report

If you encounter behavior that looks like an agent bug (not auth, timeout, or a vague objective), file an issue: github.com/LambdaTest/kane-cli/issues Include the following:

Field	How to Get It
Kane CLI version	`kane-cli --version`
OS	macOS (ARM/Intel), Linux (x64/ARM64), Windows (x64)
Chrome version	Your installed Chrome version
What happened	Describe the behavior
Reproduction steps	The exact `kane-cli run` command and objective
Expected behavior	What should have happened
Logs	The relevant section of `~/.testmuai/kaneai/sessions/<session-id>/tui.log` (redact any secrets first)

Do NOT file bug reports for: auth issues, low timeouts, vague objectives, or site-side errors (CAPTCHAs, 500 errors).

​Log Locations

​Chrome Issues

​”Chrome failed to launch”

​”CDP endpoint not reachable”

​Chrome opens then closes immediately

​Authentication Issues

​”Authentication failed” (exit code 2)

​”Not configured” on first run

​Basic auth not working

​”Login failed — fetch failed” / SSL certificate errors

​Runner: “[SSL: CERTIFICATE_VERIFY_FAILED]” behind a TLS-inspecting proxy

​Run Issues

​”Run timed out” or “max steps exceeded”

​Agent repeats the same action

​“Variables not resolving”: {{key}} appears literally

​Assertions fail even though the page looks correct

​CLI exits with code 2 and no output

​Upload Issues

​”Upload failed” or “Test Manager error”

​Agent Mode Issues

​No NDJSON output / only seeing TUI

​NDJSON parsing fails: jq errors or unexpected output

​ask_user event fires and blocks the run

​Installation Issues

​kane-cli: command not found after install

​Installation fails

​Install fails with “sharp: Please add node-addon-api”

​Mobile Issues

​”Update available” Notice

​Debugging a failed run with its evidence pack

​A --remote run refused, failed, or came back empty

​testrun says “plan invalid” or skips members

​Context sync: Git not found or too old

​Context sync: a location cannot be reached or refuses you

​Context sync: “a rebase is open” and every change is refused

​Context sync: publication could not be confirmed

​Filing a Bug Report

Log Locations

Chrome Issues

”Chrome failed to launch”

”CDP endpoint not reachable”

Chrome opens then closes immediately

Authentication Issues

”Authentication failed” (exit code 2)

”Not configured” on first run

Basic auth not working

”Login failed — fetch failed” / SSL certificate errors

Runner: “[SSL: CERTIFICATE_VERIFY_FAILED]” behind a TLS-inspecting proxy

Run Issues

”Run timed out” or “max steps exceeded”

Agent repeats the same action

“Variables not resolving”: `{{key}}` appears literally

Assertions fail even though the page looks correct

CLI exits with code 2 and no output

Upload Issues

”Upload failed” or “Test Manager error”

Agent Mode Issues

No NDJSON output / only seeing TUI

NDJSON parsing fails: `jq` errors or unexpected output

`ask_user` event fires and blocks the run

Installation Issues

`kane-cli: command not found` after install

Installation fails

Install fails with “sharp: Please add node-addon-api”

Mobile Issues

”Update available” Notice

Debugging a failed run with its evidence pack

A `--remote` run refused, failed, or came back empty

testrun says “plan invalid” or skips members

Context sync: Git not found or too old

Context sync: a location cannot be reached or refuses you

Context sync: “a rebase is open” and every change is refused

Context sync: publication could not be confirmed

Filing a Bug Report