Kernel CLI

The Kernel CLI is a fast, friendly command‑line interface for Kernel — the platform that provides sandboxed, ready‑to‑use Chrome browsers for browser automations and web agents.

Sign up at kernel.sh and read the docs.

What's Kernel?

Kernel provides sandboxed, ready-to-use Chrome browsers for browser automations and web agents. This CLI helps you deploy apps, run actions, manage browsers, and access live views.

What you can do with the CLI

• Create new Kernel applications from templates
• Deploy and version apps to Kernel
• Invoke app actions (sync or async) and stream logs
• Create, list, view, and delete managed browser sessions
• Get a live view URL for visual monitoring and remote control
• Search the web across providers and retrieve page content for results

Installation

Install the Kernel CLI using your favorite package manager:

# Using brew (recommended)
brew install onkernel/tap/kernel

# Using pnpm
pnpm install -g @onkernel/cli

# Using npm
npm install -g @onkernel/cli

Verify the installation:

which kernel
kernel --version

Quick Start

1. Create a new Kernel app:

   kernel create

2. Authenticate with Kernel:

   kernel login

3. Deploy your app:

   kernel deploy index.ts

4. Invoke your app:

   kernel invoke my-app action-name --payload '{"key": "value"}'

Authentication

OAuth 2.0 (Recommended)

The easiest way to authenticate is using OAuth:

kernel login

This opens your browser to complete the authentication flow. Choose organization-wide access or restrict the login to one project. Your credentials are securely stored, automatically refreshed, and retain the selected scope until you log in again.

API Key

You can also authenticate using an API key:

export KERNEL_API_KEY=<YOUR_API_KEY>

Create an API key from the Kernel dashboard.

Commands Reference

Global Flags

• --version, -v - Print the CLI version
• --no-color - Disable color output
• --log-level <level> - Set log level (trace, debug, info, warn, error, fatal, print)
• --project <id-or-name> - Scope requests to a project by ID or exact name (or set KERNEL_PROJECT). A non-empty flag overrides the environment variable. The selector is sent to the API as X-Kernel-Project, without a client-side project lookup. Project-scoped API keys and OAuth tokens cannot switch projects.

JSON Output

Many commands support JSON output for scripting and automation. Use --output json or -o json to get machine-readable output:

# Get browser session details as JSON
kernel browsers create -o json

# List apps as JSON
kernel app list -o json

# Deploy with JSONL streaming output (one JSON object per line)
kernel deploy index.ts -o json

Commands with JSON output support:

• Browsers: create, list, get, view
• Browser Pools: create, list, get, update, acquire
• Profiles: create, list, get, update
• Extensions: upload, list
• Proxies: create, list, get, update, check
• API Keys: create, list, get, update, rotate
• Auth Connections: timeline
• Vaults: create, list, get, credentials create/update, items list/get/events/invoke (including collect, fill, webmcp_invoke, and prepare_checkout), wallets create/payment-methods, cards create/update (display-safe public fields only)
• Projects: update
• Org: limits get/set
• Apps: list, history
• Deploy: deploy (JSONL streaming), history
• Invoke: invoke (JSONL streaming), history
• Browser Sub-commands: replays list/start, process exec/spawn, fs file-info/list-files, webmcp list, webmcp custom-tools list/add (webmcp invoke always prints JSON output)
• Browser NDJSON streaming: telemetry stream

Search

Search commands always return the full API response as JSON, including results, warnings, provider attempts, usage, and expiry. They use the normal API key or OAuth authentication and global --project scope. Your organization must have Search API access enabled.

# Discover currently configured providers and capabilities
kernel search providers

# Automatic routing
kernel search "Playwright browser automation" --max-results 5

# Retrieve a retained result without another provider call or search charge
kernel search get srch_01jsearchresult

# Use portable filters or other advanced request fields
kernel search --request '{"query":"browser automation","include_domains":["example.com"],"strict_params":true}'

# Fetch content for the top results of a retained search
kernel search contents srch_01jsearchresult --limit 3 --content-source browser

• --max-results accepts 1–100; the API may clamp it to the provider cap.
• --request accepts the complete Search API JSON object, including max_results, typed strategies (auto, pinned, or fallback), portable filters, content, include_raw, date/locale filters, and provider-specific options. It cannot be combined with a positional query, --provider, or --max-results. Provider-specific and advanced request validation is performed by the API.
• Create requests are not automatically retried, to avoid duplicate billable searches after an ambiguous failure. If a request fails ambiguously, use search get only when the API returned a retained search ID.
• Retained searches return 404 when missing, expired, or inaccessible.
• search contents <id> retrieves content for selected results of a retained search. Provide exactly one of --result-ids (in desired response order) or --limit (top N results, 1–100). --timeout-ms sets the overall deadline (1000–120000). Content options: --content-source (auto, provider, or browser; default auto), --content-format (markdown or text), --content-max-chars, --content-max-age-hours, --content-timeout-ms, --content-browser-id (reuse an existing browser session), and --content-browser-mode (curl or render). When no browser ID is given and a result needs browser retrieval, Kernel creates a temporary browser for the request; it is billed like any other browser. Requests are not automatically retried.
• To search for a literal query equal to a subcommand name (get or providers), use --request '{"query":"providers"}'.

Authentication

• kernel login [--force] - Login via OAuth 2.0
• kernel logout - Clear stored credentials
• kernel auth - Check authentication status

App Creation

• --name <name>, -n - Name of the application
• --language <language>, -l - Sepecify app language: typescript, or python
• --template <template>, -t - Template to use:
  • sample-app - Basic template with Playwright integration
  • captcha-solver - Template demonstrating Kernel's auto-CAPTCHA solver
  • stagehand - Template with Stagehand SDK (TypeScript only)
  • browser-use - Template with Browser Use SDK (Python only)
  • anthropic-computer-use - Anthropic Computer Use prompt loop
  • openai-computer-use - OpenAI Computer Use Agent sample
  • gemini-computer-use - Implements a Gemini computer use agent (TypeScript only)
  • openagi-computer-use - OpenAGI Lux computer-use models (Python only)
  • claude-agent-sdk - Claude Agent SDK browser automation agent

App Deployment

• kernel deploy <file> - Deploy an app to Kernel

  • --version <version> - Specify app version (default: latest)
  • --force - Allow overwriting existing version
  • --env <KEY=VALUE>, -e - Set environment variables (can be used multiple times)
  • --env-file <file> - Load environment variables from file (can be used multiple times)
  • --output json, -o json - Output JSONL (one JSON object per line for each event)

• kernel deploy logs <deployment_id> - Stream logs for a deployment

  • --follow, -f - Follow logs in real-time (stream continuously)
  • --since, -s - How far back to retrieve logs. Duration formats: ns, us, ms, s, m, h (e.g., 5m, 2h, 1h30m). Timestamps also supported: 2006-01-02, 2006-01-02T15:04, 2006-01-02T15:04:05, 2006-01-02T15:04:05.000
  • --with-timestamps, -t - Include timestamps in each log line

• kernel deploy history [app_name] - Show deployment history

  • --limit <n> - Max deployments to return (default: 100; 0 = all)
  • --output json, -o json - Output raw JSON array

App Management

• kernel invoke <app> <action> - Run an app action

  • --version <version>, -v - Specify app version (default: latest)
  • --payload <json>, -p - JSON payload for the action
  • --payload-file <path>, -f - Read JSON payload from a file (use - for stdin)
  • --sync, -s - Invoke synchronously (timeout after 60s)
  • --output json, -o json - Output JSONL (one JSON object per line for each event)

• kernel app list - List deployed apps

  • --name <app_name> - Filter by app name
  • --version <version> - Filter by version
  • --output json, -o json - Output raw JSON array

• kernel app history <app_name> - Show deployment history for an app

  • --limit <n> - Max deployments to return (default: 100; 0 = all)
  • --output json, -o json - Output raw JSON array

Logs

• kernel logs <app_name> - View app logs
  • --version <version> - Specify app version (default: latest)
  • --follow, -f - Follow logs in real-time
  • --since <time>, -s - How far back to retrieve logs (e.g., 5m, 1h)
  • --with-timestamps - Include timestamps in log output

Browser Management

• kernel browsers list - List running browsers
  • --query <q> - Search by name, session ID, profile ID, proxy ID, or pool name
  • --region us-east|us-west|eu-west|ap-southeast - Filter by geographic region; omit to list sessions in all regions
  • --tag <KEY=VALUE> - Filter by tag, repeatable; a session must match every pair
  • --output json, -o json - Output raw JSON array
• kernel browsers create - Create a new browser session
  • -s, --stealth - Launch browser in stealth mode to avoid detection
  • -H, --headless - Launch browser without GUI access
  • --kiosk - Launch browser in kiosk mode
  • --region us-east|us-west|eu-west|ap-southeast - Geographic region for the session. Fixed once the session is created; requires a Start-Up or Enterprise plan and defaults to us-east.
  • --private-host <host> - Destination the browser reaches directly through the session's own network instead of Kernel-managed egress, for private hosts on a VPN or tunnel the session joins (repeatable or comma-separated, max 32). Accepts hostname patterns (*.example.ts.net), IPs (10.1.30.63, [fd00::1]), and private CIDRs (100.64.0.0/10). Replaces the default private ranges (RFC1918, 100.64.0.0/10, fc00::/7); omit to keep them. Fixed once the session is created. Unrelated to a proxy's --bypass-host, which only chooses between upstream proxy and Kernel-managed direct egress.
  • --allowed-host <host> - Set an egress allowlist at creation: the only destinations the browser may reach through Kernel-managed egress (repeatable or comma-separated, max 100). Other destinations are refused with a 403 whose X-Kernel-Proxy-Error header is network_policy_denied. Filters Kernel-managed egress only, not all browser VM traffic. Accepts exact hostnames (example.com), a leading wildcard that matches subdomains but not the domain itself (*.example.com), public IPs (8.8.8.8, [2001:4860:4860::8888]), and public CIDRs (8.8.4.0/24); no ports, paths, or schemes. --start-url must be allowed. Omit for unfiltered egress; an empty list is invalid. Requires proxy v3; cannot be combined with --pool-id or --pool-name, even with --yes (set the allowlist on the pool with kernel browser-pools create/update --allowed-host). An existing list can be replaced or removed later with browsers update --allowed-host / --clear-allowed-hosts, but cannot be added later if omitted at creation or removed.
  • --proxy-route '<host>[,<host>...]=<proxy>' - Route matching browser requests through a selected proxy (repeatable, max 10 routes with 1–50 hosts each). Example: --proxy-route 'api.ipify.org,*.ipify.org=name:my-dc-proxy'. The proxy is an ID by default; use id:<id> or name:<name> explicitly. Exact hostnames beat wildcards; longer wildcard suffixes beat shorter ones. *.example.com matches subdomains, not example.com. Matching ignores case and ports. Unmatched hosts use --proxy-* or default egress. Routes apply from the start of the session, including to --start-url. Routes are create-only and cannot be combined with --pool-id/--pool-name; configure them on the pool instead.
  • --start-url <url> - Initial page to open on launch
  • --timezone <iana> - Session timezone, e.g. Europe/Berlin. Defaults to the browser region's timezone
  • --locale <bcp47> - Session locale used for languages and date and number formatting, e.g. de-DE. Defaults to the browser region's locale
  • --proxy-id <id> / --proxy-name <name> - Use that proxy for the session regardless of stealth (mutually exclusive with each other and with --proxy-mode)
  • --proxy-mode direct|default - Egress mode instead of a selected proxy: direct for no proxy regardless of stealth, default for the stealth-derived default (Kernel's stealth proxy with --stealth, direct egress otherwise). Omit all proxy flags to get the default.
  • --name <name> - Optional unique name for the session (used to find it later by name; can be changed with browsers update --name)
  • --tag <KEY=VALUE> - Set a tag on the session, repeatable; up to 50 pairs
  • --vault <id-or-name> - Attach a project-owned vault at creation (repeatable, max 20). Uses the API's effective project unless --project or KERNEL_PROJECT selects one. Cannot be combined with pool flags, even with --yes; vault bindings cannot be added to existing sessions.
  • --pool-id <id> - Acquire a browser from the specified pool (mutually exclusive with --pool-name; ignores other session flags). --name/--tag still apply to the acquired session.
  • --pool-name <name> - Acquire a browser from the pool name (mutually exclusive with --pool-id; ignores other session flags)
  • --telemetry=all - Enable telemetry for all categories
  • --telemetry=off - Disable telemetry
  • --telemetry=<list> - Per-category config, e.g. --telemetry=network=on,page=off
  • --telemetry-export-otlp <id-or-name> - Export captured telemetry over OTLP to one of the org's configured destinations. Implies --telemetry=all when --telemetry is not set, since export requires capture. Use --telemetry-export-otlp=off to disable export.
  • --telemetry-storage on|off - Whether to persist captured telemetry to Kernel storage (default on). off requires --telemetry-export-otlp <id-or-name> in the same command, so events are only available on the live stream and through the export. Cannot be changed after the browser is created.
  • --chrome-policy <json> - Custom Chrome enterprise policy as a JSON object. Kernel-managed policies (extensions, proxy, automation) are rejected server-side.
  • --chrome-policy-file <path> - Read the Chrome enterprise policy from a file (use - for stdin). Mutually exclusive with --chrome-policy.
  • --output json, -o json - Output raw JSON object
  • Note: When a pool is specified, omit other session configuration flags—pool settings determine profile, proxy, viewport, etc.
• kernel browsers delete <id-or-name> - Delete a browser by ID or name
• kernel browsers view <id-or-name> - Get live view URL for a browser by ID or name
  • --output json, -o json - Output JSON with liveViewUrl
• kernel browsers get <id-or-name> - Get detailed browser session info by ID or name
  • --output json, -o json - Output raw JSON object
• kernel browsers update <id-or-name> - Update a running browser session by ID or name
  • --name <name> - Set a new unique name for the session (mutually exclusive with --clear-name)
  • --clear-name - Clear the session name
  • --tag <KEY=VALUE> - Set a tag, repeatable; up to 50 pairs. Replaces the entire tag set (not merged); mutually exclusive with --clear-tags
  • --clear-tags - Remove all tags from the session
  • --timezone <iana> - Set the session timezone, e.g. America/Los_Angeles. Applies without restarting the browser; mutually exclusive with --clear-timezone
  • --clear-timezone - Clear the timezone override and use the browser region's default
  • --locale <bcp47> - Set the session locale, e.g. de-DE. Applies without restarting the browser; mutually exclusive with --clear-locale
  • --clear-locale - Clear the locale override and use the browser region's default
  • --telemetry=all - Enable telemetry for all categories
  • --telemetry=off - Disable telemetry
  • --telemetry=<list> - Per-category config, e.g. --telemetry=network=on,page=off
  • --proxy-id <id> / --proxy-name <name> - Switch the session to that proxy regardless of stealth (mutually exclusive with each other and with --proxy-mode)
  • --proxy-mode direct|default - Change egress mode: direct for no proxy regardless of stealth, default to restore the browser default after using a selected proxy. Changing the proxy does not change stealth or CAPTCHA solver behavior.
  • --clear-proxy - Drop the selected proxy and restore the browser default (same as --proxy-mode=default)
  • --disable-default-proxy - Connect directly instead of through the default stealth proxy (same as --proxy-mode=direct); use --disable-default-proxy=false to restore the default
  • --allowed-host <host> - Replace an existing egress allowlist only (repeatable or comma-separated, max 100), using the same entry rules as browsers create --allowed-host. PATCH cannot add an allowlist to a browser created without one or after removal. Omission leaves the existing list unchanged; an empty list is invalid. Applies without restarting the browser: new requests to destinations no longer allowed are normally refused within a few seconds and open connections to them are closed within about 30 seconds, but propagation can take up to 10 minutes during a deployment. Filters Kernel-managed egress only, not all browser VM traffic. --start-url in the same update must be allowed by the new list. Requires a browser created with proxy v3. Supported on leased pooled browsers: the pool's allowlist is restored before reuse, or the browser is destroyed if it cannot be safely restored. Mutually exclusive with --clear-allowed-hosts
  • --clear-allowed-hosts - Remove the egress allowlist and return to unfiltered egress. Once removed, an allowlist cannot be added back to that browser
  • --output json, -o json - Output raw JSON object
• kernel browsers curl <id> <url> - Make HTTP requests through a browser session's Chrome network stack
  • -X, --request <method> - HTTP method (default: GET; defaults to POST when --data is set)
  • -H, --header <header> - HTTP header, repeatable ("Key: Value" format)
  • -d, --data <body> - Request body
  • --data-file <path> - Read request body from file
  • --max-time <seconds> - Maximum time allowed for the request (default: 30)
  • -o, --output <path> - Write response body to file
  • -I, --head - Fetch headers only
  • -i, --include - Include response headers in output
  • -D, --dump-header <path> - Write received headers to file (use - for stdout)
  • -w, --write-out <format> - Output text after completion; supports %{http_code}, %{response_code}, %{time_total}, and %{size_download}
  • -f, --fail - Fail with no body output on HTTP errors
  • -s, --silent - Suppress progress output
  • Note: redirects are followed automatically by Chromium.

Vaults

Vault commands collect user credentials and manage payment credentials; fill does not submit website forms.

User credentials

Create a vault for the end user, attach it when creating a browser, then navigate to the sensitive form. Define the observed fields in the website's natural top-to-bottom order; the collection form renders this array order unchanged. Add optional non-secret labels for human-readable form text; stable names remain the state, update, and fill keys. Omit values for user collection:

kernel vaults create --name user-vault
kernel browsers create --vault user-vault
kernel vaults credentials create user-vault login --spec-file - <<'JSON'
{"description":"Hacker News","fields":[{"name":"username","label":"Username","type":"text","required":true,"sensitive":false},{"name":"password","label":"Password","type":"password","required":true,"sensitive":true}]}
JSON
kernel vaults items get user-vault login --wait 60 -o json
kernel vaults items invoke user-vault login fill --spec-file - <<'JSON'
{"browser_id":"<browser-id>","fields":[{"field":"username","selector":"#username"},{"field":"password","selector":"#password"}]}
JSON

Present the returned collection URL to the user before waiting for ready. It is a bearer credential: share it only with that user. Readiness means required values are populated, not that login succeeded. fill requires an already-open page and never navigates or submits it. Optional page_url selects the exact page; cards require it. Fill is safe to retry after a failed/unknown outcome; do not fall back to aliases. Once ready, use fill for ordinary web forms. When the item advertises webmcp_invoke, use items webmcp invoke instead to bind credential fields to existing null inputs of a live WebMCP tool; the tool may submit or have other side effects (see Invoke WebMCP tools with vault fields). 1Password credentials use their own advertised 1pw_* operations instead.

Create specs list fields as an ordered array. Each entry carries a stable name (letters, digits, and underscores, starting with a letter) that keys values, updates, and fills. Order is preserved: list fields in the same top-to-bottom order as the website, because the collection form renders that order unchanged. An optional label supplies non-secret display text for that field on the collection form; it never affects value keys, updates, or fills. Use a single trimmed line of at most 128 UTF-8 bytes, and it is returned as metadata in get/list output.

Use credentials update <vault> <key> --version <version> --spec-file changes.json with a spec such as {"fields":{"password":{"value":"replacement"}}}; update specs key fields by name rather than using the ordered array. Keep actual secrets in protected files or stdin, never shell arguments. Omission preserves values; null or an empty string clears supported fields, including required text/email/password fields (returning them to pending collection). The form still requires nonempty required inputs. Field definitions cannot change. Stale versions fail, without retries. items invoke <vault> <key> collect reopens the full form without clearing values; compare versions to observe edits to already-ready items. When an update is bound to an earlier read, also pass --expected-item-id <id> to reject a replacement item at the same key. Neither precondition is refreshed automatically.

Do not use credential items to store, collect, or fill credit card data, including card numbers (PANs), security codes (CVV/CVC), or expiration dates. Use wallet and card item types for credit cards and payment checkout instead.

Set description to the recognizable site name only, such as Hacker News, not Hacker News sign-in credentials. Set sensitive: false explicitly for ordinary usernames and email addresses. Reserve sensitive: true for passwords, API tokens, and TOTP seeds; the omitted default remains true for safety.

Types are text, email, password, and totp. TOTP seeds must be provided through create/update, never the form; only generated codes enter the browser. Unrestricted browser access can read filled values. CLI JSON output retains explicitly non-sensitive text/email values, definitions, version, and has_value. Sensitive values and TOTP seeds are omitted. Credential spec input is capped at 128 KiB; write errors are redacted.

To reuse a managed auth connection's saved credential, create a credential with provider managed_auth and the connection ID from kernel auth connections list. The item stores no values and reads the connection's credential at fill time; it is created ready, state.fields lists fill binding names, and update returns 409:

kernel vaults credentials create user-vault amazon --spec-file - <<'JSON'
{"provider":"managed_auth","connection_id":"<connection-id>","description":"Amazon"}
JSON

Vault names, item keys, and project ownership are immutable. Optionally select a project with --project <id-or-name> or KERNEL_PROJECT; otherwise, the API resolves the project from your credentials and its defaults (the default project for org-wide credentials, not all projects). Ownership is assigned from that scope, not a project_id body field. Project-scoped credentials cannot switch projects.

Command reference

| Command | Purpose / flags | | --- | --- | | kernel vaults create --name <name> | Create or retrieve the vault with that immutable name | | kernel vaults list | --limit 1..100 (default 20), --offset, --query (name substring or exact ID); JSON includes vaults and optional next_offset | | kernel vaults get <vault> | Get by ID or name | | kernel vaults get-encryption-key <vault> | Get the public key custom collection apps use to send encrypted_value | | kernel vaults delete <vault> | Invalidate the vault and all its items; --yes skips confirmation | | kernel vaults wallets create <vault> <key> --provider link\|agentcard\|kernel --spec '<json>' | Connect/enroll a wallet using its provider's spec; --open opens a returned HTTPS action URL | | kernel vaults wallets get <vault> <key> | Observe wallet state and its hosted action; --wait 0..60, --open | | kernel vaults wallets payment-methods <vault> <key> | Fetch advertised live payment methods; JSON is the item with expanded.payment_methods | | kernel vaults cards create <vault> <key> --provider link\|agentcard\|kernel --spec '<json>' | Create a card request without authorizing it | | kernel vaults cards update <vault> <key> --provider link\|agentcard --spec '<json>' | Update a card spec before it is authorized at a checkout; pending issuance preserves omitted optional fields, and the API enforces state/provider constraints | | kernel vaults items list <vault> | List item keys, types, providers, status, and required actions | | kernel vaults items get <vault> <key> | Inspect state/actions/returned AgentCard aliases and copyable operation commands; --wait 0..60, --expand payment_methods, --open | | kernel vaults items invoke <vault> <key> <operation> | GET the item, then POST an advertised operation; authorize --browser-id <id> --page-url <url> authorizes a Link card at checkout; authorize --open opens a returned HTTPS action; prepare_checkout --params '<json>' prepares an unused AgentCard card for Square Pay; fill --params '<json>' fills checkout or login fields; collect --open opens a credential item's hosted form | | kernel vaults items webmcp invoke <vault> <key> | Invoke a live WebMCP tool with item fields bound to null input slots; --browser-id, --tool-ref, --page-url, --input/--input-file, repeatable --bind <field>=<json-pointer>, --timeout-sec 1..120. Same as items invoke <vault> <key> webmcp_invoke --params '<json>' | | kernel vaults items events <vault> <key> | Read ordered audit events; --after <event-id>, --wait 0..60 | | kernel vaults items delete <vault> <key> | Invalidate an item; --yes skips confirmation |

<vault> accepts an ID or name. <key> is the immutable item key within that vault, not its generated item ID. Names and keys use letters, digits, dots, underscores, and hyphens (1–255 characters; not . or ..). All commands except delete support -o json. JSON preserves field presence and API-returned AgentCard aliases, while omitting unknown fields, opaque metadata, and unrecognized event data. Human output labels aliases as non-secret checkout values and distinguishes card readiness from checkout authorization/payment outcomes. Link and Kernel cards do not expose aliases or support egress substitution; browser checkout uses only advertised fill. Action and approval URLs print in full on separate lines, without table truncation. Most API failures use the CLI's standard error formatter. Wallet creation and provider config commands withhold response/transport details to prevent credential echoes; HTTP status remains visible. vaults delete and vaults items delete treat HTTP 404 as success and print Deleted or not found, whether the missing object is the project, vault, or item. Other API errors still return a nonzero exit status.

Provider specifications: wallet creation and card creation/update require --provider and --spec '<json>'. Supply only the spec object, not a {type, spec} envelope. The command sets the item type and injects provider; if JSON also contains provider, it must match. Other non-secret values are forwarded unchanged, including optional fields, without defaults or normalization. The API validates the provider-specific schema. Each command's --help includes its raw TypeScript-style types, which must stay in sync with the API spec.

• Kernel wallet: use {}; no provider configuration or token file is accepted. The hosted card_enrollment action collects card details from the cardholder, never from the CLI.
• Link wallet: supply authorization: {method: "oauth", client: {type: "kernel_managed"}}.
• AgentCard wallet: use {} to enroll, or supply user_id for a user enrolled in the same organization and provider configuration.
• Kernel card: supply wallet, amount (minor units, at most 1000000), currency, merchant_name, and HTTPS merchant_url. Supply two-letter merchant_country for Visa. Kernel card updates are unsupported.
• Link card: include the required fields shown in help. Optional line_items, totals, metadata, and expires_at are supported through JSON. amount is at most 500000 minor units; a virtual card allows at most 50000.
• AgentCard card: uses merchant, not Link's merchant_name. Its optional card_id selects a vaulted card; otherwise the cardholder selects one at approval.

cards update replaces the spec for supported providers' requested cards; Kernel cards cannot be updated. Pending issuance updates preserve omitted optional fields; explicit empty lists clear them. Wallet/provider bindings and unsupported fields cannot change after authorization starts. Checkout cards can be edited between authorizations, but a Link card authorized at a checkout cannot be updated (the API returns 409): delete it and create a new one. An uncertain update enters recovery_required and must not be retried. Identical card creation returns its existing state without polling, reauthorizing, or resetting recovery. Link fill is limited to the origin of the checkout the card was authorized at; AgentCard checkout domains remain provider-assigned; Kernel fill is locked to the exact origin of merchant_url. Neither command submits a merchant payment.

Provider configurations and imported grants

Provider configurations are organization-owned and shared across projects. Creating, updating, or deleting one requires organization-scoped authentication; selecting --project does not elevate a project-scoped API key. Existing Kernel-managed wallet commands remain unchanged.

| Command | Purpose | | --- | --- | | kernel vault-provider-configs create --name <name> --provider link\|agentcard --credentials-file <path\|-> | Register client credentials; file JSON contains client_id and client_secret strings. Link: --publishable-key sets the Stripe publishable key Kernel needs to refresh and revoke imported wallet grants | | kernel vault-provider-configs list | --limit 1..100, --offset; JSON includes vault_provider_configs and optional next_offset | | kernel vault-provider-configs get <id-or-name> | Show public metadata (show is an alias); AgentCard test_mode is introspected, not selectable | | kernel vault-provider-configs update <id-or-name> | --name renames; --credentials-file rotates using a JSON object containing only client_secret; --publishable-key sets the Link publishable key | | kernel vault-provider-configs delete <id-or-name> | Delete only when no non-deleted items reference it; --yes skips confirmation |

Config commands support -o json except delete. Secrets never appear in list/get/write output. Omitted update fields stay unchanged. Provider and client ID are immutable; rotation must preserve identity and mode and affects every bound wallet. Renaming preserves the config ID and wallet bindings. Duplicate config creation returns a conflict, not credential replacement. Deletion does not delete the external client or revoke unrelated grants.

Use protected credential files or pipe directly from your secret manager with --credentials-file -. Never put secrets in shell arguments, --spec, or command examples. For an existing protected file:

kernel vault-provider-configs create --name checkout-client --provider agentcard \
  --credentials-file /secure/provider-client.json
kernel vaults wallets create checkout wallet-1 --provider agentcard --spec '{}' \
  --provider-config-name checkout-client --open

Wallet creation accepts either --provider-config-id or --provider-config-name, not both. Alternatively, AgentCard accepts provider_config: {id: ...} or {name: ...} in its spec. Do not combine a spec reference with selection flags. Bindings are immutable and responses return the resolved ID. Omitting selection preserves Kernel-managed credentials.

Link config credentials and wallet grants are different inputs. The config stores the OAuth client credentials. Your backend must complete Link OAuth and obtain a currently valid access and refresh token pair from the same grant before importing a wallet. After successful import, stop refreshing that grant in your backend: Kernel owns subsequent refresh-token rotation.

kernel vault-provider-configs create --name link-client --provider link \
  --credentials-file /secure/link-client.json --publishable-key pk_live_...
kernel vaults wallets create checkout imported-wallet --provider link --spec '{}' \
  --provider-config-name link-client --tokens-file /secure/link-grant.json

The protected grant file must contain only access_token and refresh_token JSON string fields; --tokens-file - reads the same object from stdin. With Link selection flags, omit spec.authorization. Alternatively, set authorization.method to oauth and its client to {type: "customer_managed", provider_config: {id: ...}} in --spec, still using --tokens-file. Tokens are never accepted in --spec or returned in display output.

Repeating wallet creation never replaces an imported grant. If it becomes degraded, complete fresh OAuth in your backend and import a new wallet key for new work only. This does not rebind existing cards or resolve old payments. Retain old items while reconciling uncertain payments; do not repeat an uncertain payment through the new wallet. There is no in-place imported-wallet reauthorization.

recovery_required means unresolved, not declined or expired. It stops server-side waiting. If restart_verification is advertised in available_operations, invoke with explicit user approval each time to get a fresh spend_approval link. The cardholder must verify and approve spending again; restart grants no spend consent. If the response is unclear, re-get and share any new action; invoke once more only if still advertised with renewed user approval. Otherwise do not retry payment, delete or replace the item. Contact [email protected] privately with project, vault, key, status_reason and relevant event timestamps (never card data, API keys or capability URLs) to reconcile the original operation and establish whether a new purchase is safe; never assume a new card is safe. Unresolved child cards can block wallet and vault deletion. Time passing or deletion is not evidence of non-execution.

Kernel-managed card checkout

kernel vaults create --name checkout
kernel vaults wallets create checkout cardholder --provider kernel --spec '{}' --open
kernel vaults wallets get checkout cardholder --wait 60
kernel vaults wallets payment-methods checkout cardholder

Share the returned card_enrollment URL with the cardholder. A connected wallet may still report single_use_card.eligible: false with a network_token_* reason while network token enrollment is pending or unsupported. Re-check network_token_pending later at most once in this attempt; network_token_unsupported, network_token_failed, or persistent ineligibility requires a different card, enrolled under a new wallet key after user confirmation. Missing eligibility is unknown. Never poll indefinitely. For reconnect_required, share the new enrollment action. For degraded, obtain user confirmation and delete only if the API permits it before a new wallet/enrollment; reconcile unresolved child cards first. This wallet uses its enrolled card, not a payment_method_id in the card spec.

kernel vaults cards create checkout order-1 --provider kernel --spec '{
  "wallet":"cardholder", "amount":1200, "currency":"USD",
  "merchant_name":"Example Shop", "merchant_url":"https://shop.example/checkout",
  "merchant_country":"US"
}'
kernel vaults items get checkout order-1
kernel vaults items invoke checkout order-1 authorize --open
kernel vaults items get checkout order-1 --wait 60

Only invoke authorize when advertised. Visa returns a spend_approval URL for the cardholder to verify and approve; Mastercard may become ready without one. In recovery_required, invoke restart_verification only if advertised, with explicit user approval each time:

kernel vaults items invoke checkout order-1 restart_verification --open

This rotates the approval link locally without a provider call, only after a classified initial attestation failure with proof no intent was dispatched. Otherwise do not retry, delete, or replace the item. Always check available_operations rather than assuming the API supports this operation. Human output, JSON output and execution expose only advertised restart_verification during recovery; other operations and stale action URLs are suppressed.

--open on enrollment or spend-approval URLs is only for a human cardholder using their own machine. Agents must omit it and share the capability URL privately; never open it for the cardholder. The examples with --open are for human use. Optional merchant_category and merchant_category_code (actual four-digit MCC other than 0000) are accepted; omit rather than invent them. Kernel cards cannot be updated: with user confirmation, delete only if permitted and create a new item under a new key; reconcile unresolved outcomes first.

When ready, create a browser with the vault attached, navigate to checkout, then fill:

kernel browsers create --vault checkout
kernel vaults items invoke checkout order-1 fill --params '{
  "browser_id":"<returned-browser-session-id>",
  "page_url":"https://shop.example/checkout",
  "fields":[
    {"field":"number","selector":"#cardNumber"},
    {"field":"expiration","format":"MM/YY","selector":"#cardExpiry"},
    {"field":"cvc","selector":"#cardCvc"}
  ]
}' -o json

Use the exact current HTTPS top-level URL on merchant_url's origin and selectors matching that page. Supported fields are number, expiration (format MM/YY or MM/YYYY), cvc, exp_month and exp_year. Kernel cards have no stored billing fields: requesting billing_* returns 400 field_unavailable before any write. Enter billing details (such as name and ZIP) directly on the merchant page. Fill types the one-time network token and code but never submits checkout. Submit before expires_at; neither ready nor fill proves payment.

After the user submits checkout, report the observed merchant outcome exactly once, only when confirm_transaction is advertised. For example, after observing approval:

kernel vaults items invoke checkout order-1 confirm_transaction --params '{
  "status":"APPROVED", "transaction_type":"PURCHASE", "amount":1200,
  "currency":"USD", "occurred_at":"2026-09-01T12:00:00Z"
}'

--spec-file <path|-> accepts the same JSON. All five fields are required; do not include type or any extra properties. status must be APPROVED, DECLINED, PENDING, ERROR, or CANCELLED. transaction_type must be PURCHASE, AUTHORIZATION, CAPTURE, REFUND, REVERSAL, VERIFICATION, CHARGEBACK, or FRAUD. amount is an integer in minor units, 0..1000000 and no greater than the approved amount; currency is three uppercase letters matching the approved purchase currency; occurred_at is the observed outcome's RFC3339 timestamp. The operation is no longer advertised after reporting. Never infer success from fill. PENDING means explicit merchant evidence of an accepted pending transaction; ERROR means an explicit merchant transaction error, not transport loss or an ambiguous processing page. These are final reports, not polling states. Unknown outcomes need the user to check merchant orders, email or statements, then report the confirmed outcome even after card expiry. If a report response is lost, re-get and send the identical observed report once more only if freshly advertised; otherwise observe state/events (recorded, in flight or recovery). Never repeat checkout. After a confirmed merchant decline, report DECLINED when advertised; if the user wants another purchase, ask for a different card or merchant, delete only if permitted and create one new card under a new key. Expired approval/code before checkout: do not submit; with user confirmation delete only if permitted and create one new card. If checkout was submitted, reconcile and report the observed outcome first.

Kernel request errors retain actionable API messages while scrubbing HTTP(S) URLs. After create transport/5xx failure, retry once with the identical key and spec, never a new key to recover a lost response. After authorize/report failures re-get and invoke once more only if freshly advertised. Authorize 409 requires state inspection, not input changes. For 429 wait for Retry-After before re-checking availability. No automatic retries. Never put PAN, CVC, expiry, or enrollment credentials in CLI arguments or logs.

Link card checkout

Each item's available_operations descriptions and the Link wallet's description are authoritative; items get prints them. The flow:

1. Connect the wallet once, in the provider's UI:

   kernel vaults create --name checkout
   kernel vaults wallets create checkout wallet-1 --provider link \
     --spec '{"authorization":{"method":"oauth","client":{"type":"kernel_managed"}}}' --open
   kernel vaults items get checkout wallet-1 --wait 60

2. Reach the final checkout page in a browser created with the vault attached. Note the amount, currency, merchant name and URL, and choose a funding method:

   kernel browsers create --vault checkout
   kernel vaults wallets payment-methods checkout wallet-1

3. Create the card. This does not contact Link; the card is requested and advertises authorize. To change the amount or merchant before authorizing, use cards update.

   kernel vaults cards create checkout order-1 --provider link --spec '{
     "wallet": "wallet-1",
     "payment_method_id": "<returned-id>",
     "amount": 1234,
     "currency": "usd",
     "merchant_name": "Example Shop",
     "merchant_url": "https://shop.example",
     "context": "Purchase the selected office supplies from Example Shop for the approved order, with a total spending limit of 1234 minor currency units."
   }'

4. Once the user has approved this purchase, and only when the item advertises authorize, authorize at the checkout with the browser session ID and the exact current top-level checkout URL. Pass both flags or neither. KERNEL inspects the checkout, chooses how the credential is delivered (a Link Pay Token or a virtual card), limits fill to that checkout's origin, and sends the user an approval request. Do not inspect or invoke WebMCP yourself.

   kernel vaults items invoke checkout order-1 authorize \
     --browser-id <browser-session-id> --page-url https://shop.example/checkout

5. Share the approval URL from the item's action with the user, then wait until fill is advertised. To re-check sooner, invoke authorize again; checkout context is not needed, and re-checking never creates another payment request.

   kernel vaults items get checkout order-1 --wait 60

6. Fill as the item's fill description says, in any browser with the vault attached. A Link Pay Token takes browser_id and page_url and omits fields; a virtual card also takes field/selector bindings (see Fill browser fields).

   kernel vaults items invoke checkout order-1 fill \
     --params '{"browser_id":"<browser-session-id>","page_url":"https://shop.example/checkout"}' -o json

7. Submit the checkout yourself; fill never submits payment. Failed or unknown fills are safe to retry, but only after checking the page and not in an automatic loop.

Recovery:

• Authorize errors page_not_found, ambiguous_page, browser_not_found, browser_unavailable, destination_denied, timeout, and browser_error happen before any payment request. The CLI prints the code and message. Make sure the checkout is open in exactly one tab at page_url, then authorize again. If checkout inspection keeps failing, authorize without --browser-id and --page-url to issue a virtual card that fills any page on the merchant_url origin.
• Once a card is authorized at a checkout, cards update returns 409: delete the card and create a new one.
• If authorization is declined or expires, read status_reason, then delete the card and create a new one.
• If the amount exceeds the 50000 minor-unit virtual card limit on a checkout without Link Pay Token support, delete the card and tell the user.
• If the result of submitting payment is unclear, check the merchant's order confirmation or order history before paying again. items events shows the card's recorded events.

AgentCard checkout preparation

For a separate AgentCard flow, create a vault and complete the wallet enrollment action:

kernel vaults create --name agentcard-checkout
kernel vaults wallets create agentcard-checkout wallet-1 --provider agentcard --spec '{}' --open
kernel vaults items get agentcard-checkout wallet-1 --wait 60

Once the wallet is connected, create the card request:

kernel vaults cards create agentcard-checkout order-1 --provider agentcard --spec '{
  "wallet": "wallet-1",
  "merchant": "Example Shop",
  "amount": 1234,
  "currency": "usd",
  "checkout_origin": "https://shop.example.com"
}'
kernel browsers create --vault agentcard-checkout

AgentCard authorizes at checkout and does not currently advertise authorize. For non-prepared authorization, optional checkout_origin declares the merchant origin for eligible AgentCard autopilot rule matching. Use a canonical HTTPS origin with a lowercase host, no default port, and no path, such as https://shop.example.com; HTTP localhost is allowed for test pages. Kernel forwards the declaration but does not validate it against the page open in the browser. Omitting it retains the current approval flow. Supplying it does not enable autopilot by itself: if autopilot does not apply, user approval may still be required, and it does not guarantee payment success. Prepared checkout uses preparation.merchant_origin instead.

To select a vaulted card in advance, inspect wallets payment-methods and include its ID as card_id in the card spec. Otherwise, the cardholder selects a card at approval. AgentCard-only state.aliases support egress substitution with checkout hold, approval, and replay in a browser with the vault attached. This is not a fallback after Link fill. A reusable card being ready does not mean the last payment succeeded.

Invoking item operations

items get displays every available_operations entry's type and description, plus an items invoke command retaining the selected project (replace <json> for operations with parameters). Read the description and follow its approval requirements before invoking. Required user actions (OAuth, enrollment, MFA, spend approval) appear separately; they are not operations to invoke through this endpoint.

items invoke fetches the item again and calls POST /vaults/{id_or_name}/items/{key}/operations only if the requested operation is still advertised. In recovery_required, the CLI hides and refuses every operation except an advertised restart_verification, invoked with explicit user approval each time and new cardholder spend consent. Human and JSON output use the same recovery filtering. Other operations remain blocked; otherwise contact [email protected] with project, vault, key, status_reason and event timestamps (no card data, API keys or capability URLs). Do not delete or replace unresolved items. Stale action URLs in recovery are not opened; a successful restart returns a fresh approval action.

authorize sends {"type":"authorize"} without --params and returns the updated item, possibly with a required user action. For a Link card at checkout, --browser-id and --page-url (both or neither) add browser_id and page_url. collect is also parameterless and returns a credential collection URL. restart_verification is parameterless and sends {"type":"restart_verification"}. --open is supported for authorize, collect, prepare_checkout, 1pw_recover, and restart_verification. fill, prepare_checkout, and confirm_transaction accept inputs in --params or --spec-file <path|-> (mutually exclusive, maximum 128 KiB). The positional operation supplies type; including type in either input is rejected. Parameters must be a JSON object without unknown or duplicate properties. There is no operation --spec flag; wallet/card --spec flags remain unchanged. New parameterless operations can still be invoked by name when advertised.

Prepare an AgentCard checkout

For an unused AgentCard card, invoke prepare_checkout only when advertised:

kernel vaults items invoke user-123 order-1 prepare_checkout --params '{"checkout":{"browser_id":"browser-session-id","merchant_origin":"https://shop.example","environment":"production"}}' --open
kernel vaults items get user-123 order-1 --wait 60 -o json

--spec-file <path|-> accepts the same JSON. browser_id is the active session with this vault attached. merchant_origin is the canonical HTTPS origin of the top-level merchant document, not a processor iframe; HTTP localhost is allowed for tests.

Optional psp selects the checkout processor: square, braintree, worldpay, bambora, mercado_pago, or adyen. Omit it for Square; non-Square processors require multi-processor preparation enablement. environment is production, sandbox, or shared: use production or sandbox for Square, Braintree, Worldpay and Adyen, and shared for Bambora and Mercado Pago. Shared endpoints do not establish test mode; merchant credentials and configuration determine processor test mode, independently of the AgentCard credential mode.

adyen supports fresh-card Sessions requests on Adyen hosts only. Fill the public dummy card fields rather than vault aliases, and keep the approval page open through device handoff, including Adyen encryption. The unique armed preparation is associated with the next eligible request from the declared browser and merchant origin; competing preparations are rejected. Adyen device approval and browser Authorised responses are not capture or fulfillment evidence.

Keep the approval page open. Poll until the item's status is ready_to_submit, then submit native Pay before state.preparation.expires_at. Readiness lasts at most 30 seconds, and polling does not extend it. The CLI displays the preparation ID, status, browser, origin, environment, processor, approval URL, and submission deadline.

Each preparation is single-use, including after failure or expiry. A preparation marked consumed has been claimed; it does not prove the payment settled or succeeded. Do not automatically retry or switch checkout paths after an uncertain result.

Fill browser fields

Fill supports credential items and ready Link or Kernel cards when advertised by the API, not AgentCard. All use the same execution and outcome handling. Credential bindings use declared field names, including TOTP fields, and must omit format. Credentials may omit page_url only when the API can resolve a unique page. Cards require an exact HTTPS page_url. Follow the item's advertised fill description for the rest: a Link Pay Token omits fields; other cards use the card fields listed below. The vault must already be attached to the browser for fill authorization. Fill writes real stored values into the browser without returning them in the result; unrestricted browser/CDP access can read those values. It does not explicitly submit forms or click buttons, though input/change events may trigger site behavior:

kernel vaults items get checkout order-1
kernel vaults items invoke checkout order-1 fill --params '{"browser_id":"browser-session-id","page_url":"https://shop.example/checkout","fields":[{"field":"number","selector":"#card-number"},{"field":"expiration","format":"MM/YY","selector":"#expiry"},{"field":"cvc","selector":"#security-code"}],"timeout_ms":10000}' -o json

• browser_id is a browser session ID, not a reusable browser name. It is sent unchanged; the CLI does not resolve names.
• For cards, page_url is the exact current top-level HTTPS URL, including path, query, and fragment, without embedded credentials. It must match exactly one open page; no prefix/glob matching.
• fields, when the item's fill description asks for it, contains 1-32 bindings in write order. Each has field and a nonempty CSS selector targeting an editable input/select or its container. The API searches the selected page and descendants, including payment iframes. Do not supply frame IDs or literal values.
• Link virtual card fields: number, cvc, exp_month (MM), exp_year (YYYY), billing_name, billing_line1, billing_line2, billing_city, billing_state, billing_postal_code, billing_country. Billing fields use the stored address without reformatting; request only needed fields. Missing requested billing data fails validation before browser writes.
• Kernel cards support number, expiration, cvc, exp_month, and exp_year, with no stored billing fields. billing_* returns 400 field_unavailable before any write; enter billing details on the merchant page. Fill is restricted to merchant_url's origin.
• Combined card expiration requires format: "MM/YY" or "MM/YYYY". Other fields reject format.
• Deprecated timeout_ms is accepted for compatibility as an integer from 1 to 30000, but the API ignores it. Fill sets no operation deadline and adapts typing pace to value length.

Fill returns an execution result, not an updated item. Normal output shows zero-based field indices, statuses, and error codes. -o json preserves the display-safe result shape:

{"type":"fill","status":"unknown","fields":[{"index":0,"status":"filled"},{"index":1,"status":"unknown","error_code":"timeout"},{"index":2,"status":"not_attempted"}]}

completed exits 0; failed and unknown exit nonzero with the result still on stdout, without appended error text. API/transport errors exit nonzero with a sanitized diagnostic on stderr, not a fabricated execution result. No values, selectors, DOM content, or raw browser errors are printed in fill results. Pre-write API rejections (400/403/404/409) retain HTTP status, recognized error codes, and corrective guidance, and confirm that the request wrote no fields. Correct the cause and retry. Transport loss and other uncertain failures note that fields may have been written and that fill is safe to retry.

Fill is non-atomic: execution stops at the first failed/unknown field and earlier writes are not rolled back. filled does not mean the site retained or accepted the value; completed does not mean logged in or paid. Transport errors do not prove no writes occurred. Fill never submits, so it is safe to run again. The CLI does not retry automatically, explicitly submit website forms, or fall back to aliases. Link and Kernel cards do not expose state.aliases or support egress substitution. AgentCard-only checkout aliases are a separate integration, not a recovery path after a failed or indeterminate fill.

Invoke WebMCP tools with vault fields

webmcp_invoke calls a live WebMCP tool with values from a credential item or ready Link card, when the item advertises it. Discover the tool first, then pass its opaque tool_ref and exact source.page_url (fragment omitted). The vault must already be attached to the browser. Put null at each input slot a vault field fills; --input holds only public tool arguments, never vault values:

kernel browsers webmcp list <browser-id> -o json
kernel vaults items webmcp invoke user-vault resy \
  --browser-id <browser-id> --tool-ref <tool-ref> --page-url https://resy.com/login \
  --input '{"email":null,"password":null}' \
  --bind email=/email --bind password=/password -o json

• Each --bind <field>=<json-pointer> maps one vault field to an RFC 6901 JSON Pointer to an existing null in input (no root or - append paths; array indices must be canonical and in range). Each field and path may be bound once; 1-32 bindings. Card expiration uses --bind expiration:MM/YY=/card/expiry (or MM/YYYY); other fields take no format. TOTP fields supply a fresh code, never the seed.
• --timeout-sec is 1-120 (API default 15). Input numbers are sent unchanged; input is capped at 64 KiB.
• The equivalent request body for items invoke <vault> <key> webmcp_invoke --params/--spec-file is {"browser_id":"...","tool_ref":"...","page_url":"...","input":{...},"bindings":[{"field":"email","input_path":"/email"}],"timeout_sec":15}.

The tool may submit forms or perform other side effects. The result returns status, invocation_id, output, and error_text as the API returns them; output and error_text are untrusted page-provided data and may contain the supplied vault values:

{"type":"webmcp_invoke","status":"completed","invocation_id":"invoke-1","output":{"authenticated":true}}

completed and awaiting_submission exit 0; neither confirms the website accepted the action. After awaiting_submission, submit the populated form through Playwright or computer interaction instead of invoking the tool again. canceled, error, and unknown exit nonzero with the result still on stdout in -o json. unknown means the tool may have run. API rejections (400/403/404/409) mean the tool was not invoked by that request; other failures and transport loss are uncertain, so inspect the browser to see whether the tool ran.

Expansions, updates, and lifecycle

--expand takes a value, such as --expand payment_methods; it is not a boolean switch. Request only expansions advertised in available_expansions. Add -o json to read the returned expanded.payment_methods directly. Unavailable expansions return an API error.

Use cards update <vault> <key> --provider <provider> --spec '<json>' to replace the entire card spec when the API permits it. Include optional fields you want to retain; the CLI does not merge the new JSON with the existing spec.

Waits are single bounded observations, not readiness guarantees or payment retries. Pending state is returned as-is. Requests are not automatically retried by the vault commands. Never automatically retry failed, timed-out, rejected, or indeterminate payments. Inspect state/events and reconcile the outcome instead. If an AgentCard recovery state explicitly permits user-confirmed abandonment, delete that card before creating a replacement; deletion does not prove the original attempt failed. Do not pass card data, OAuth codes/tokens, ciphertext, provider secrets, or sensitive provider responses to the CLI. Complete collection, OAuth, and approval actions through the provider's returned URL/UI; no callback-code command exists.

Browser Pools

• kernel browser-pools list - List browser pools
  • --region us-east|us-west|eu-west|ap-southeast - Filter by geographic region; omit to list pools in all regions
  • --output json, -o json - Output raw JSON array
• kernel browser-pools create - Create a browser pool
  • --name <name> - Optional unique name for the pool
  • --size <n> - Number of browsers in the pool (required)
  • --fill-rate <n> - Percentage of the pool to fill per minute
  • --timeout <seconds> - Idle timeout for browsers acquired from the pool
  • --stealth, --headless, --kiosk - Default pool configuration
  • --memory 8GiB|16GiB - Memory for headful browsers in the pool (default 8GiB)
  • --refresh-on-profile-update - Flush idle browsers when the pool's profile is updated (requires a profile)
  • --profile-id, --profile-name, --proxy-id, --region, --start-url, --extension, --viewport, --private-host, --proxy-route, --allowed-host - Same semantics as kernel browsers create (proxy routes and the egress allowlist apply to every browser warmed into the pool). Leased browsers can replace or remove the allowlist with kernel browsers update; per-lease changes are reset to the pool's allowlist on release, or the browser is replaced
  • --chrome-policy <json> / --chrome-policy-file <path> - Custom Chrome enterprise policy applied to every browser in the pool, as a JSON object or from a file (- for stdin). Same semantics as kernel browsers create.
  • --telemetry=all / --telemetry=off / --telemetry=<categories> - Telemetry applied to browsers warmed into the pool. Same semantics as kernel browsers create.
  • --output json, -o json - Output raw JSON object
• kernel browser-pools get <id-or-name> - Get pool details
  • --output json, -o json - Output raw JSON object
• kernel browser-pools update <id-or-name> - Update pool configuration
  • Same flags as create (except --region, which is fixed at creation and cannot be updated) plus --clear-profile, --clear-proxy, --clear-start-url, --clear-extensions, --clear-chrome-policy, --clear-private-hosts, --clear-proxy-routes, and --clear-allowed-hosts for removing durable configuration. --clear-private-hosts removes the whole network configuration (restoring the default private IP ranges and dropping proxy routes and the allowlist). --private-host, --proxy-route, --allowed-host, --clear-proxy-routes, and --clear-allowed-hosts replace the pool's whole network configuration, so pass the other network flags to keep them; any network update without --allowed-host removes the pool's allowlist. Any change to the pool's allowlist, including removing it, automatically replaces idle browsers; leased browsers keep their allowlist until release, when it is reset to the new list or the browser is replaced. --fill-rate 0 pauses automatic filling. --discard-all-idle discards all idle browsers and refills the pool. --telemetry, --memory, and other network updates only apply to browsers warmed after the update.
  • --output json, -o json - Output raw JSON object
• `kernel