Configuration

Kane CLI stores persistent settings at ~/.testmuai/kaneai/tui-config.json. Most settings are managed through kane-cli config subcommands; a few are managed through interactive pickers in TUI mode, and one (code export) is toggled from the TUI menu.

Authentication credentials are managed 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

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	""	Path to a Chrome user-data dir. Empty means a fresh profile per run.	kane-cli config chrome-profile [path]
default_url	string | null	https://kaneai-playground.lambdatest.io	Starting URL when a run begins.	Internal default
model	string	"v16-alpha"	Reasoning + vision model used by the agent.	Internal default
project_id	string | null	null	TestMu AI Test Manager project ID for upload	kane-cli config project [id]
project_name	string | null	null	Display name of the selected project	Set by kane-cli config project
folder_id	string | null	null	TestMu AI Test Manager folder ID for upload	kane-cli config folder [id]
folder_name	string | null	null	Display name of the selected folder	Set by kane-cli config folder
mode	"action" | "testing"	"testing"	Agent behaviour on auth walls, blocked pages, or error pages.	kane-cli config set-mode <action|testing>
target	"desktop" | "emulator" | "simulator"	"desktop"	Default run target. desktop runs the Chrome browser; emulator and simulator run against a virtual Android or iOS device (macOS Apple Silicon only). 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>
code_export.enabled	boolean	false	Generate code export after upload completes.	TUI menu, or --code-export flag
code_export.language	"python" | "javascript"	"python"	Output language for generated code. Accepts python or javascript.	--code-language <lang>
code_export.skip_validation	boolean	true	Skip post-codegen worker-side validation.	TUI menu, or --skip-code-validation

---

Updating Settings

Window Size

The Chrome window is launched at the configured resolution:

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, the same setting can be edited through an interactive window-size picker.

Test Manager Project

kane-cli config project

In a TTY, this opens an interactive project picker. The picker fetches the projects available to your active profile, lets you search and arrow-key through them, and saves the chosen project_id and project_name. Login is required before the picker can fetch projects.

You can also set a project ID directly without the picker:

kane-cli config project <project-id>

See Test Manager Integration for how project selection feeds into uploads.

Test Manager Folder

kane-cli config folder

Opens an interactive folder picker for the currently selected project. Folders are searchable and shown with their hierarchy. You must have a project selected first.

To set a folder ID without the picker:

kane-cli config folder <folder-id>

See Test Manager Integration for how folder selection feeds into uploads.

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 expect the agent to push through gates that would otherwise stop a real user.
• action: the agent hard-stops on authentication, blocked, and error pages so you can intervene manually before the run proceeds.

You can override the saved mode for a single run with --mode <action|testing> on kane-cli run.

Mobile Target

On macOS Apple Silicon, Kane CLI can run against a virtual mobile device on this machine instead of the desktop browser. Four settings persist the default target and how to reach it. They are a separate axis from mode above: mode tunes agent behaviour, while these choose what 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. Existing web runs are unaffected.
• device_name and os_version: the device a mobile run selects, in the vocabulary of kane-cli devices list --target <kind>. A name needs a version, and a version on its own matches any device running it. When unset, a TTY run prompts once and saves the 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, a build path (emulator .apk, simulator .zip) or an uploaded app id, APP followed by six or more digits. Required for every mobile run. On the desktop target, device and app are ignored.

A run reads these as its defaults. Override any of them for a single run with --target, --device-name, --os-version, and --app. Setup and the full list of accepted app formats are in Mobile Testing. These defaults describe devices on this machine. A testrun run --remote run names its device from the grid catalog with the same two flags.

Code Export

The code_export block enables and configures generated code output produced after a successful Test Manager upload. There is no kane-cli config subcommand for this block. Set it from one of:

• The TUI: open the config menu, choose Code Export, and toggle the enabled and skip_validation switches.
• Per-run flags on kane-cli run:
  • --code-export to enable for this run only
  • --code-language <lang> to pick the output language (python or javascript)
  • --skip-code-validation / --no-skip-code-validation to control post-codegen validation

Code export requires a Test Manager upload, so it is only meaningful when a project is configured. 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 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.

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. It is the right choice for CI and other environments without a display.

Window Size

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

Chrome environment variables

A handful of environment variables control how kane-cli locates and launches Chrome. They are read from the process environment, not from tui-config.json, so they are convenient 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.

The CDP timeout and retry settings only affect transient launch failures (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 reads a few environment variables, never 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), for an HTTPS proxy that rejects chunked uploads, where 33554432 is 32 MiB. Larger values cost memory, and the 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

There is no kane-cli config reset subcommand. To reset persistent settings to defaults, delete the config file:

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

Kane CLI recreates the file with defaults the next time it writes 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/