How to Configure Kane CLI

Kane CLI saves its settings in ~/.testmuai/kaneai/tui-config.json. You change most settings with kane-cli config subcommands. A few also have interactive pickers in TUI mode, and one (code export) is switched on and off from the TUI menu. This page covers the settings saved in tui-config.json. Authentication credentials are stored separately under ~/.testmuai/kaneai/profiles/. See Authentication.

Viewing Settings

Print the current configuration:

kane-cli config show

The output groups settings under three headings:

Configuration

Auth
  method   oauth | basic (user@example.com) | not configured
  profile  default
  env      prod

Defaults
  url      https://kaneai-playground.lambdatest.io
  model    v16-alpha
  mode     testing
  window   1920x1080
  project  (none)
  folder   (none)

Paths
  chrome   /Users/you/.testmuai/kaneai/chrome-profiles/work

Empty fields are shown as (none). The chrome path is empty by default, in which case Kane CLI launches Chrome with a temporary profile each run.

Settings Reference

Every field in tui-config.json:

Field	Type	Default	Description	How to Change
`window_size.width`	integer	`1920`	Chrome window width in pixels (800–3840)	`kane-cli config set-window <WxH>`
`window_size.height`	integer	`1080`	Chrome window height in pixels (600–2160)	`kane-cli config set-window <WxH>`
`chrome_profile_path`	string	`""`	Filesystem path to a Chrome user-data dir. Empty means a fresh, temporary profile is used per run.	`kane-cli config chrome-profile [path]`
`default_url`	string \| null	`https://kaneai-playground.lambdatest.io`	Default start URL for a run, used when neither `--url` nor a test.md `url:` key supplies one. The built-in playground value is treated as “unset”. See Default start URL.	`kane-cli config set-url <url>`
`model`	string	`"v16-alpha"`	Reasoning + vision model used by the agent.	Internal default
`project_id`	string \| null	`null`	Test Manager project ID for upload	`kane-cli config project [id]`
`project_name`	string \| null	`null`	Display name of the selected project (set automatically by the picker)	Set by `kane-cli config project`
`folder_id`	string \| null	`null`	Test Manager folder ID for upload	`kane-cli config folder [id]`
`folder_name`	string \| null	`null`	Display name of the selected folder (set automatically by the picker)	Set by `kane-cli config folder`
`mode`	`"action"` \| `"testing"`	`"testing"`	Agent behaviour when the run hits an authentication wall, blocked page, or error page. See Mode.	`kane-cli config set-mode <action\|testing>`
`target`	`"desktop"` \| `"emulator"` \| `"simulator"`	`"desktop"`	Default run target. `desktop` runs the Chrome browser, the default. `emulator` and `simulator` run against a virtual Android or iOS device on this machine (macOS Apple Silicon only). Other hosts use `testrun run --remote`. See Mobile Target.	`kane-cli config set-target <desktop\|emulator\|simulator>`
`device_name`	string \| null	`null`	Default mobile device, by the name `kane-cli devices list --target <kind>` prints. Pairs with `os_version`. When empty, a TTY run prompts once and saves the choice. A non-interactive run needs `--device-name` or this key set. Ignored on the `desktop` target.	`kane-cli config set-device-name <name>`
`os_version`	string \| null	`null`	OS version of the default mobile device (`14`, `17.5`). Required alongside `device_name`.	`kane-cli config set-os-version <version>`
`app`	string \| null	`null`	Default app under test for mobile runs: a build path (`.apk` or `.zip`) or an uploaded app id. Ignored on the `desktop` target.	`kane-cli config set-app <path\|APPid>`
`bug_detection`	`"off"` \| `"stop"` \| `"continue"`	`"off"`	Whether the agent flags suspected product bugs while authoring. See Bug detection.	`kane-cli config set-bug-detection <mode>`, or per-run `--bug-detection`
`code_export.enabled`	boolean	`true`	Whether to generate a code export after the upload pipeline completes (requires a Test Manager upload).	TUI menu, or per-run `--code-export` flag
`code_export.language`	`"python"` \| `"javascript"`	`"python"`	Output language for generated code. Accepts `python` or `javascript`.	Per-run `--code-language <lang>`
`code_export.skip_validation`	boolean	`true`	Skip the worker-side validation step that runs after code is generated.	TUI menu, or per-run `--skip-code-validation` / `--no-skip-code-validation`

Updating Settings

Window Size

The Chrome window is launched at the configured resolution. Update it from the CLI:

kane-cli config set-window 1280x800

The format is WIDTHxHEIGHT (lowercase x separator). Width must be between 800 and 3840; height must be between 600 and 2160. Invalid values are rejected without changing the saved config. In TUI mode, you can also use an interactive window-size picker. Type the width and height, and the picker checks the limits and previews the new size before saving.

Default start URL

Every run needs a start URL for its first navigation. Kane CLI checks these sources in order and uses the first one that supplies a URL:

The --url <url> flag on kane-cli run / kane-cli testmd run.
(test.md only) the url: key in the file’s frontmatter.
The configured default_url, set with config set-url.

kane-cli config set-url https://app.example.com

You can pass a bare domain, and Kane CLI adds the scheme: config set-url example.com stores https://example.com. If the value is not a valid URL, Kane CLI rejects it and leaves the saved config unchanged. The built-in playground value (https://kaneai-playground.lambdatest.io) counts as “unset”, so a fresh install behaves as if no default is configured. In TUI mode, set the same value with /config set-url <url>, or pick Default URL from the interactive /config menu. If none of these three sources supplies a URL, Kane CLI uses a site named in the objective itself (for example, “Go to amazon.com and …”). If there is still no start URL, an interactive terminal asks you for one, and a non-interactive (CI) run fails. To let a non-interactive run start from the browser’s current page instead, pass --allow-missing-url. See Run options.

Test Manager Project

kane-cli config project

In an interactive terminal, this opens a project picker. The picker loads the projects available to your active profile, lets you search and move through them with the arrow keys, and saves the chosen project_id and project_name. You must be logged in for the picker to load projects. Either OAuth or basic-auth credentials work. You can also set a project ID directly without the picker:

kane-cli config project <project-id>

In a non-interactive shell (CI, pipes), pass an explicit <project-id>. To discover the right ID first, use kane-cli projects list (see Test Manager Integration). If you do not configure a project, Kane CLI picks a sensible default when your first run starts. See Auto-default on first run. See Test Manager Integration for how project selection feeds into uploads.

Test Manager Folder

kane-cli config folder

This opens an interactive folder picker for the selected project. You can search the folders, which are shown with their hierarchy. The picker saves both folder_id and folder_name. Select a project first. OAuth and basic-auth profiles both work. To set a folder ID without the picker:

kane-cli config folder <folder-id>

To look up folder IDs from a script or another non-interactive shell, use kane-cli folders list. See Test Manager Integration. See Test Manager Integration for how folder selection feeds into uploads.

Self-healing for stale IDs

A configured project or folder can become unusable: it was deleted or renamed, you lost access, or you typed an invalid ID by mistake. Kane CLI detects the bad ID on the next run, clears it, and picks a new default. This prevents the run from going ahead with a dead ID and the upload failing silently. To choose a project yourself, run kane-cli config project again (or kane-cli projects list followed by kane-cli config project <id>).

Mode

kane-cli config set-mode action
kane-cli config set-mode testing

mode controls how the agent behaves when a run hits an authentication wall, a blocked page, or an error page:

testing (default): the agent treats those pages as part of the run and continues. Use this when you have set up the test and expect the agent to get past gates that would stop a real user.
action: the agent stops on authentication, blocked, and error pages so you can step in manually before the run continues.

To override the saved mode for a single run, pass --mode <action|testing> to kane-cli run.

Mobile Target

On macOS Apple Silicon, Kane CLI can run against a virtual mobile device on your machine instead of the desktop browser. Four settings save the default target and the device and app to use. They are independent of mode above: mode controls agent behaviour, while these choose which device a run drives.

kane-cli config set-target emulator                 # desktop | emulator | simulator
kane-cli config set-device-name "Pixel 7 API 35"    # as `kane-cli devices list --target emulator` prints it
kane-cli config set-os-version 15
kane-cli config set-app ./builds/app-debug.apk

target: desktop, the default, runs Chrome. emulator runs a virtual Android device and simulator a virtual iOS device. Web runs are not affected by the mobile settings.
device_name and os_version: the device a mobile run uses, named exactly as kane-cli devices list --target <kind> prints it. A name needs a version. A version on its own matches any device on that version. When these are unset, an interactive run asks once and saves your choice. Non-interactive runs need them set, either here or with --device-name and --os-version.
app: the app under test for a mobile run. Use a build path (emulator .apk, simulator .zip) or an uploaded app id, which is APP followed by six or more digits. Every mobile run requires an app. On the desktop target, the device settings and app are ignored.

A run uses these settings as its defaults. To override any of them for a single run, pass --target, --device-name, --os-version, or --app. Setup steps and the full list of accepted app formats are in Mobile Testing. These defaults describe local devices. A testrun run --remote run picks its device from the grid catalog with the same two flags (--device-name and --os-version).

Bug detection

kane-cli config set-bug-detection continue

bug_detection controls whether the agent watches for product bugs, not test failures, while it authors steps. When it is on, the agent can flag suspicious behaviour during the run, such as a broken flow, a wrong value, or an unexpected error. Kane CLI investigates each suspicion and either rejects it (the run continues and nothing fails) or confirms it as a product bug:

off (default): the agent does not watch for product bugs.
stop: a confirmed product bug fails the step and ends the run.
continue: the confirmed bug is recorded (in the run result and the evidence pack) and the run keeps going.

This setting applies to authoring steps only. Replayed steps do not need it, because a failed replay is always investigated automatically. To override the saved value for a single run, pass --bug-detection <off|stop|continue> to kane-cli run, kane-cli testmd run, or kane-cli testrun run. The setting appears as Bug Detection in the TUI Config screen and in the kane-cli config show output.

Assertion and capture controls

kane-cli config set-assertion-mode dom|visual: how assertions are checked. The default is dom, which falls back to vision when needed. Override it for one run with --assertion-mode dom|visual on run or testmd run.
kane-cli config set-final-validation on|off: turns the synthesized final checkpoint (cp_final) on or off. The default is off. Override it for one run with --final-validation on|off on run or testmd run. This setting works independently of action/testing mode, so keep writing explicit assertions at the end of your objectives.
kane-cli config set-network-ws on|off and set-network-sse on|off: experimental capture of WebSocket and SSE traffic. Both are off by default. run also accepts --network-ws and --network-sse. SSE capture works in Chromium only. testmd run and testrun run do not accept these flags.

Code Export

Code export turns a run into runnable code after a successful Test Manager upload. It supports Python and JavaScript, and it is on by default. A value saved in the code_export block of tui-config.json overrides the default. There is no kane-cli config subcommand for code export. Change it in one of these ways:

The TUI: open the config menu, choose Code Export, and switch enabled and skip_validation on or off. The TUI saves the change to tui-config.json.
Per-run flags on kane-cli run:
- --code-export to turn it on for this run only
- --code-language <lang> to pick the output language (python or javascript; default python)
- --skip-code-validation / --no-skip-code-validation to skip or run the worker-side validation after code is generated

Code export needs a Test Manager upload, and a project and folder that you configured or that Kane CLI picked by default. The mode setting does not affect uploads; it controls only agent behaviour. See Test Manager Integration for the full upload pipeline.

Chrome Management

Chrome Profile

By default, chrome_profile_path is empty and Kane CLI launches Chrome with a fresh, temporary user-data directory each run. A clean per-run profile keeps state out of your everyday browser, isolates cookies and storage between runs, and prevents extensions, password autofill, or signed-in sessions from leaking into automation. When you select a named Chrome profile, Kane CLI stores it under ~/.testmuai/kaneai/chrome-profiles/<name> and reuses that directory across runs. This is useful when a test depends on having a logged-in session, a saved address, or a specific extension installed.

Choosing a Different Profile

kane-cli config chrome-profile

In a TTY, this opens an interactive Chrome-profile picker. The picker lists every profile under ~/.testmuai/kaneai/chrome-profiles/ plus a “temporary” entry that clears the path back to empty (per-run fresh profiles). You can also create a new named profile from the picker: Kane CLI creates the directory under ~/.testmuai/kaneai/chrome-profiles/<name> and saves the path. To set a path directly without the picker:

kane-cli config chrome-profile /absolute/path/to/profile

Headless Mode

To run Chrome without a visible window, pass --headless on kane-cli run:

kane-cli run "Verify the home page loads" --headless

Headless mode is per-run; there is no persistent setting in tui-config.json. It is the right choice for CI and other environments without a display.

Window Size

The Chrome window dimensions used for both headed and headless modes come from the window_size setting. See Window Size above to update them.

Chrome environment variables

A few environment variables control how Kane CLI finds and launches Chrome. Kane CLI reads them from the environment, not from tui-config.json, which makes them handy for CI and one-off overrides.

Variable	Effect
`KANE_CLI_CHROME_PATH`	Absolute path to the Chrome binary. Use it when Chrome is installed somewhere kane-cli does not search by default.
`KANE_CLI_SKIP_BROWSER_DOWNLOAD`	Any truthy value (`1` / `true` / `yes`) bypasses the Chrome-availability startup check; kane-cli then uses whatever `chrome` resolves on `PATH`. Useful in air-gapped or pre-provisioned CI images.
`KANE_CLI_CDP_TIMEOUT_MS`	Per-attempt timeout, in milliseconds, for Chrome to become reachable over the DevTools Protocol. Default `30000`. Raise it on slow or cold CI runners.
`KANE_CLI_CDP_RETRIES`	Extra Chrome launch attempts after the first when CDP readiness fails. Default `2` (so up to three attempts total); set `0` for a single attempt. Each retry uses a short backoff.

CDP is the Chrome DevTools Protocol, which Kane CLI uses to connect to Chrome. The CDP timeout and retry settings affect only temporary launch failures, where Chrome started but did not become reachable in time. A missing or invalid binary fails immediately without retrying. See Chrome failed to launch for the matching troubleshooting steps.

Context sync environment variables

Sharing the context graph uses the following environment variables. It never reads these values from tui-config.json.

Variable	Effect
`KANE_SYNC_GIT_TOKEN`	A token for a GitHub location over HTTPS in CI: a repository-scoped personal access token with Contents read and write, or a GitHub App installation token. Read at use time, never written to disk or put on a command line. A workflow’s own `GITHUB_TOKEN` reaches only that workflow’s repository, so a separate context repository needs its own token or an SSH deploy key.
`KANE_SYNC_S3_ACCESS_KEY_ID` and `KANE_SYNC_S3_SECRET_ACCESS_KEY`	The access key pair for an S3-compatible location, read at use time. Both must be set, and together they win over the saved credential file. Never written to disk, which is the CI form.
`KANE_SYNC_GUARD`	`0` turns off the advisory line a write command prints when a teammate has pushed past this machine (`origin has moved past this machine — run kane-cli context pull origin`, or `this store and origin have diverged — run kane-cli context pull origin --rebase`). The check writes nothing, refuses nothing, and gives up silently after 1.5 seconds.
`KANE_SYNC_GIT_TRANSFER_TIMEOUT_SECONDS`	How long one Git transfer (fetch, push) may take, `60` to `3600`. Default 15 minutes. Raise it for a slow link or a very large first fetch.
`KANE_SYNC_GIT_HTTP_POST_BUFFER`	Git’s HTTP upload buffer, in bytes, for that command (1 MiB to 512 MiB). Use it with an HTTPS proxy that rejects chunked uploads. For example, `33554432` is 32 MiB. Larger values use more memory. When the variable is unset, Git’s default is unchanged.
`KANE_CONTEXT_GITIGNORE`	`0` stops Kane CLI from adding `.context/` to your `.gitignore` when it creates the store inside a git repository.

Two places on disk belong to sharing and are not touched by a settings reset:

Path	Holds
`~/.testmuai/kaneai/context-sync/<name>.json`	the saved S3 key pair for the location named `<name>`, readable by you only (mode `0600`). `kane-cli context sync remove <name>` deletes it. The file belongs to the name, not to one store: every store on this machine whose location is called `<name>` reads it, and binding another bucket under that name from any store replaces it, so give each bucket its own name.
`~/.testmuai/kaneai/context-sync/mirrors/`	Kane CLI’s own cache of each GitHub location (bare Git objects, no checkout). Safe to delete, and the next command fetches again.

Resetting Settings

To reset persistent settings to defaults, delete the config file:

rm ~/.testmuai/kaneai/tui-config.json

Kane CLI creates a new file with default values the next time it saves a setting. This only resets tui-config.json. It does not affect:

Authentication credentials under ~/.testmuai/kaneai/profiles/ (use kane-cli logout)
Session history under ~/.testmuai/kaneai/sessions/
Variables under ~/.testmuai/kaneai/variables/ and .testmuai/variables/
Chrome profiles under ~/.testmuai/kaneai/chrome-profiles/
Context sync credentials and caches under ~/.testmuai/kaneai/context-sync/ (use kane-cli context sync remove <name> to delete a location’s keys)

​Viewing Settings

​Settings Reference

​Updating Settings

​Window Size

​Default start URL

​Test Manager Project

​Test Manager Folder

​Self-healing for stale IDs

​Mode

​Mobile Target

​Bug detection

​Assertion and capture controls

​Code Export

​Chrome Management

​Chrome Profile

​Choosing a Different Profile

​Headless Mode

​Window Size

​Chrome environment variables

​Context sync environment variables

​Resetting Settings

Viewing Settings

Settings Reference

Updating Settings

Window Size

Default start URL

Test Manager Project

Test Manager Folder

Self-healing for stale IDs

Mode

Mobile Target

Bug detection

Assertion and capture controls

Code Export

Chrome Management

Chrome Profile

Choosing a Different Profile

Headless Mode

Window Size

Chrome environment variables

Context sync environment variables

Resetting Settings