agent-browser
Headless browser automation CLI for AI agents. Fast native Rust CLI.
Installation
Global Installation (recommended)
Installs the native Rust binary:
Project Installation (local dependency)
For projects that want to pin the version in package.json:
Then use via package.json scripts or by invoking agent-browser directly.
Homebrew (macOS)
From Source
Linux Dependencies
On Linux, install system dependencies:
Requirements
- Chrome - Run
agent-browser installto download Chrome from Chrome for Testing (Google's official automation channel). No Playwright or Node.js required for the daemon. - Rust - Only needed when building from source (see From Source above).
Quick Start
Traditional Selectors (also supported)
Commands
Core Commands
Get Info
Check State
Find Elements (Semantic Locators)
Actions: click, fill, type, hover, focus, check, uncheck, text
Options: --name <name> (filter role by accessible name), --exact (require exact text match)
Examples:
Wait
# Wait for text/element to disappear
Load states: load, domcontentloaded, networkidle
Clipboard
Mouse Control
Browser Settings
Cookies & Storage
Network
Tabs & Windows
Frames
Dialogs
Diff
Debug
Navigation
Setup
Authentication
agent-browser provides multiple ways to persist login sessions so you don't re-authenticate every run.
Quick summary
| Approach | Best for | Flag / Env |
|---|---|---|
| Persistent profile | Full browser state (cookies, IndexedDB, service workers, cache) across restarts | --profile <path> / AGENT_BROWSER_PROFILE |
| Session persistence | Auto-save/restore cookies + localStorage by name | --session-name <name> / AGENT_BROWSER_SESSION_NAME |
| Import from your browser | Grab auth from a Chrome session you already logged into | --auto-connect + state save |
| State file | Load a previously saved state JSON on launch | --state <path> / AGENT_BROWSER_STATE |
| Auth vault | Store credentials locally (encrypted), login by name | auth save / auth login |
Import auth from your browser
If you are already logged in to a site in Chrome, you can grab that auth state and reuse it:
# 1. Launch Chrome with remote debugging enabled
# macOS:
# Or use --auto-connect to discover an already-running Chrome
# 2. Connect and save the authenticated state
# 3. Use the saved auth in future sessions
# 4. Or use --session-name for automatic persistence
# From now on, --session-name myapp auto-saves/restores this state
Security notes:
--remote-debugging-portexposes full browser control on localhost. Any local process can connect. Only use on trusted machines and close Chrome when done.- State files contain session tokens in plaintext. Add them to
.gitignoreand delete when no longer needed. For encryption at rest, setAGENT_BROWSER_ENCRYPTION_KEY(see State Encryption).
For full details on login flows, OAuth, 2FA, cookie-based auth, and the auth vault, see the Authentication docs.
Sessions
Run multiple isolated browser instances:
# Different sessions
# Or via environment variable
AGENT_BROWSER_SESSION=agent1
# List active sessions
# Output:
# Active sessions:
# -> default
# agent1
# Show current session
Each session has its own:
- Browser instance
- Cookies and storage
- Navigation history
- Authentication state
Persistent Profiles
By default, browser state (cookies, localStorage, login sessions) is ephemeral and lost when the browser closes. Use --profile to persist state across browser restarts:
# Use a persistent profile directory
# Login once, then reuse the authenticated session
# Or via environment variable
AGENT_BROWSER_PROFILE=/.myapp-profile
The profile directory stores:
- Cookies and localStorage
- IndexedDB data
- Service workers
- Browser cache
- Login sessions
Tip: Use different profile paths for different projects to keep their browser state isolated.
Session Persistence
Alternatively, use --session-name to automatically save and restore cookies and localStorage across browser restarts:
# Auto-save/load state for "twitter" session
# Login once, then state persists automatically
# State files stored in ~/.agent-browser/sessions/
# Or via environment variable
State Encryption
Encrypt saved session data at rest with AES-256-GCM:
# Generate key: openssl rand -hex 32
# State files are now encrypted automatically
| Variable | Description |
|---|---|
AGENT_BROWSER_SESSION_NAME |
Auto-save/load state persistence name |
AGENT_BROWSER_ENCRYPTION_KEY |
64-char hex key for AES-256-GCM encryption |
AGENT_BROWSER_STATE_EXPIRE_DAYS |
Auto-delete states older than N days (default: 30) |
Security
agent-browser includes security features for safe AI agent deployments. All features are opt-in -- existing workflows are unaffected until you explicitly enable a feature:
- Authentication Vault -- Store credentials locally (always encrypted), reference by name. The LLM never sees passwords. A key is auto-generated at
~/.agent-browser/.encryption-keyifAGENT_BROWSER_ENCRYPTION_KEYis not set:echo "pass" | agent-browser auth save github --url https://github.com/login --username user --password-stdinthenagent-browser auth login github - Content Boundary Markers -- Wrap page output in delimiters so LLMs can distinguish tool output from untrusted content:
--content-boundaries - Domain Allowlist -- Restrict navigation to trusted domains (wildcards like
*.example.comalso match the bare domain):--allowed-domains "example.com,*.example.com". Sub-resource requests (scripts, images, fetch) and WebSocket/EventSource connections to non-allowed domains are also blocked. Include any CDN domains your target pages depend on (e.g.,*.cdn.example.com). - Action Policy -- Gate destructive actions with a static policy file:
--action-policy ./policy.json - Action Confirmation -- Require explicit approval for sensitive action categories:
--confirm-actions eval,download - Output Length Limits -- Prevent context flooding:
--max-output 50000
| Variable | Description |
|---|---|
AGENT_BROWSER_CONTENT_BOUNDARIES |
Wrap page output in boundary markers |
AGENT_BROWSER_MAX_OUTPUT |
Max characters for page output |
AGENT_BROWSER_ALLOWED_DOMAINS |
Comma-separated allowed domain patterns |
AGENT_BROWSER_ACTION_POLICY |
Path to action policy JSON file |
AGENT_BROWSER_CONFIRM_ACTIONS |
Action categories requiring confirmation |
AGENT_BROWSER_CONFIRM_INTERACTIVE |
Enable interactive confirmation prompts |
See Security documentation for details.
Snapshot Options
The snapshot command supports filtering to reduce output size:
| Option | Description |
|---|---|
-i, --interactive |
Only show interactive elements (buttons, links, inputs) |
-C, --cursor |
Include cursor-interactive elements (cursor:pointer, onclick, tabindex) |
-c, --compact |
Remove empty structural elements |
-d, --depth <n> |
Limit tree depth |
-s, --selector <sel> |
Scope to CSS selector |
The -C flag is useful for modern web apps that use custom clickable elements (divs, spans) instead of standard buttons/links.
Annotated Screenshots
The --annotate flag overlays numbered labels on interactive elements in the screenshot. Each label [N] corresponds to ref @eN, so the same refs work for both visual and text-based workflows.
Annotated screenshots are supported on the CDP-backed browser path (Chrome/Lightpanda). The Safari/WebDriver backend does not yet support --annotate.
# -> Screenshot saved to /tmp/screenshot-2026-02-17T12-00-00-abc123.png
# [1] @e1 button "Submit"
# [2] @e2 link "Home"
# [3] @e3 textbox "Email"
After an annotated screenshot, refs are cached so you can immediately interact with elements:
This is useful for multimodal AI models that can reason about visual layout, unlabeled icon buttons, canvas elements, or visual state that the text accessibility tree cannot capture.
Options
| Option | Description |
|---|---|
--session <name> |
Use isolated session (or AGENT_BROWSER_SESSION env) |
--session-name <name> |
Auto-save/restore session state (or AGENT_BROWSER_SESSION_NAME env) |
--profile <path> |
Persistent browser profile directory (or AGENT_BROWSER_PROFILE env) |
--state <path> |
Load storage state from JSON file (or AGENT_BROWSER_STATE env) |
--headers <json> |
Set HTTP headers scoped to the URL's origin |
--executable-path <path> |
Custom browser executable (or AGENT_BROWSER_EXECUTABLE_PATH env) |
--extension <path> |
Load browser extension (repeatable; or AGENT_BROWSER_EXTENSIONS env) |
--args <args> |
Browser launch args, comma or newline separated (or AGENT_BROWSER_ARGS env) |
--user-agent <ua> |
Custom User-Agent string (or AGENT_BROWSER_USER_AGENT env) |
--proxy <url> |
Proxy server URL with optional auth (or AGENT_BROWSER_PROXY env) |
--proxy-bypass <hosts> |
Hosts to bypass proxy (or AGENT_BROWSER_PROXY_BYPASS env) |
--ignore-https-errors |
Ignore HTTPS certificate errors (useful for self-signed certs) |
--allow-file-access |
Allow file:// URLs to access local files (Chromium only) |
-p, --provider <name> |
Cloud browser provider (or AGENT_BROWSER_PROVIDER env) |
--device <name> |
iOS device name, e.g. "iPhone 15 Pro" (or AGENT_BROWSER_IOS_DEVICE env) |
--json |
JSON output (for agents) |
--full, -f |
Full page screenshot |
--annotate |
Annotated screenshot with numbered element labels (or AGENT_BROWSER_ANNOTATE env) |
--screenshot-dir <path> |
Default screenshot output directory (or AGENT_BROWSER_SCREENSHOT_DIR env) |
--screenshot-quality <n> |
JPEG quality 0-100 (or AGENT_BROWSER_SCREENSHOT_QUALITY env) |
--screenshot-format <fmt> |
Screenshot format: png, jpeg (or AGENT_BROWSER_SCREENSHOT_FORMAT env) |
--headed |
Show browser window (not headless) (or AGENT_BROWSER_HEADED env) |
--cdp <port|url> |
Connect via Chrome DevTools Protocol (port or WebSocket URL) |
--auto-connect |
Auto-discover and connect to running Chrome (or AGENT_BROWSER_AUTO_CONNECT env) |
--color-scheme <scheme> |
Color scheme: dark, light, no-preference (or AGENT_BROWSER_COLOR_SCHEME env) |
--download-path <path> |
Default download directory (or AGENT_BROWSER_DOWNLOAD_PATH env) |
--content-boundaries |
Wrap page output in boundary markers for LLM safety (or AGENT_BROWSER_CONTENT_BOUNDARIES env) |
--max-output <chars> |
Truncate page output to N characters (or AGENT_BROWSER_MAX_OUTPUT env) |
--allowed-domains <list> |
Comma-separated allowed domain patterns (or AGENT_BROWSER_ALLOWED_DOMAINS env) |
--action-policy <path> |
Path to action policy JSON file (or AGENT_BROWSER_ACTION_POLICY env) |
--confirm-actions <list> |
Action categories requiring confirmation (or AGENT_BROWSER_CONFIRM_ACTIONS env) |
--confirm-interactive |
Interactive confirmation prompts; auto-denies if stdin is not a TTY (or AGENT_BROWSER_CONFIRM_INTERACTIVE env) |
--engine <name> |
Browser engine: chrome (default), lightpanda (or AGENT_BROWSER_ENGINE env) |
--config <path> |
Use a custom config file (or AGENT_BROWSER_CONFIG env) |
--debug |
Debug output |
Configuration
Create an agent-browser.json file to set persistent defaults instead of repeating flags on every command.
Locations (lowest to highest priority):
~/.agent-browser/config.json-- user-level defaults./agent-browser.json-- project-level overrides (in working directory)AGENT_BROWSER_*environment variables override config file values- CLI flags override everything
Example agent-browser.json:
Use --config <path> or AGENT_BROWSER_CONFIG to load a specific config file instead of the defaults:
AGENT_BROWSER_CONFIG=./ci-config.json
All options from the table above can be set in the config file using camelCase keys (e.g., --executable-path becomes "executablePath", --proxy-bypass becomes "proxyBypass"). Unknown keys are ignored for forward compatibility.
Boolean flags accept an optional true/false value to override config settings. For example, --headed false disables "headed": true from config. A bare --headed is equivalent to --headed true.
Auto-discovered config files that are missing are silently ignored. If --config <path> points to a missing or invalid file, agent-browser exits with an error. Extensions from user and project configs are merged (concatenated), not replaced.
Tip: If your project-level
agent-browser.jsoncontains environment-specific values (paths, proxies), consider adding it to.gitignore.
Default Timeout
The default timeout for standard operations (clicks, waits, fills, etc.) is 25 seconds. This is intentionally below the CLI's 30-second IPC read timeout so that the daemon returns a proper error instead of the CLI timing out with EAGAIN.
Override the default timeout via environment variable:
# Set a longer timeout for slow pages (in milliseconds)
Note: Setting this above 30000 (30s) may cause EAGAIN errors on slow operations because the CLI's read timeout will expire before the daemon responds. The CLI retries transient errors automatically, but response times will increase.
| Variable | Description |
|---|---|
AGENT_BROWSER_DEFAULT_TIMEOUT |
Default operation timeout in ms (default: 25000) |
Selectors
Refs (Recommended for AI)
Refs provide deterministic element selection from snapshots:
# 1. Get snapshot with refs
# Output:
# - heading "Example Domain" [ref=e1] [level=1]
# - button "Submit" [ref=e2]
# - textbox "Email" [ref=e3]
# - link "Learn more" [ref=e4]
# 2. Use refs to interact
Why use refs?
- Deterministic: Ref points to exact element from snapshot
- Fast: No DOM re-query needed
- AI-friendly: Snapshot + ref workflow is optimal for LLMs
CSS Selectors
Text & XPath
Semantic Locators
Agent Mode
Use --json for machine-readable output:
# Returns: {"success":true,"data":{"snapshot":"...","refs":{"e1":{"role":"heading","name":"Title"},...}}}
Optimal AI Workflow
# 1. Navigate and get snapshot
# 2. AI identifies target refs from snapshot
# 3. Execute actions using refs
# 4. Get new snapshot if page changed
Command Chaining
Commands can be chained with && in a single shell invocation. The browser persists via a background daemon, so chaining is safe and more efficient:
# Open, wait for load, and snapshot in one call
&& &&
# Chain multiple interactions
&& &&
# Navigate and screenshot
&& &&
Use && when you don't need intermediate output. Run commands separately when you need to parse output first (e.g., snapshot to discover refs before interacting).
Headed Mode
Show the browser window for debugging:
This opens a visible browser window instead of running headless.
Note: Browser extensions work in both headed and headless mode (Chrome's
--headless=new).
Authenticated Sessions
Use --headers to set HTTP headers for a specific origin, enabling authentication without login flows:
# Headers are scoped to api.example.com only
# Requests to api.example.com include the auth header
# Navigate to another domain - headers are NOT sent (safe!)
This is useful for:
- Skipping login flows - Authenticate via headers instead of UI
- Switching users - Start new sessions with different auth tokens
- API testing - Access protected endpoints directly
- Security - Headers are scoped to the origin, not leaked to other domains
To set headers for multiple origins, use --headers with each open command:
For global headers (all domains), use set headers:
Custom Browser Executable
Use a custom browser executable instead of the bundled Chromium. This is useful for:
- Serverless deployment: Use lightweight Chromium builds like
@sparticuz/chromium(~50MB vs ~684MB) - System browsers: Use an existing Chrome/Chromium installation
- Custom builds: Use modified browser builds
CLI Usage
# Via flag
# Via environment variable
AGENT_BROWSER_EXECUTABLE_PATH=/path/to/chromium
Serverless (Vercel)
Run agent-browser + Chrome in an ephemeral Vercel Sandbox microVM. No external server needed:
import { Sandbox } from "@vercel/sandbox";
const sandbox = await Sandbox.create({ runtime: "node24" });
await sandbox.runCommand("agent-browser", ["open", "https://example.com"]);
const result = await sandbox.runCommand("agent-browser", ["screenshot", "--json"]);
await sandbox.stop();
See the environments example for a working demo with a UI and deploy-to-Vercel button.
Serverless (AWS Lambda)
import chromium from '@sparticuz/chromium';
import { BrowserManager } from 'agent-browser';
export async function handler() {
const browser = new BrowserManager();
await browser.launch({
executablePath: await chromium.executablePath(),
headless: true,
});
// ... use browser
}
Local Files
Open and interact with local files (PDFs, HTML, etc.) using file:// URLs:
# Enable file access (required for JavaScript to access local files)
# Take screenshot of a local PDF
The --allow-file-access flag adds Chromium flags (--allow-file-access-from-files, --allow-file-access) that allow file:// URLs to:
- Load and render local files
- Access other local files via JavaScript (XHR, fetch)
- Load local resources (images, scripts, stylesheets)
Note: This flag only works with Chromium. For security, it's disabled by default.
CDP Mode
Connect to an existing browser via Chrome DevTools Protocol:
# Start Chrome with: google-chrome --remote-debugging-port=9222
# Connect once, then run commands without --cdp
# Or pass --cdp on each command
# Connect to remote browser via WebSocket URL
The --cdp flag accepts either:
- A port number (e.g.,
9222) for local connections viahttp://localhost:{port} - A full WebSocket URL (e.g.,
wss://...orws://...) for remote browser services
This enables control of:
- Electron apps
- Chrome/Chromium instances with remote debugging
- WebView2 applications
- Any browser exposing a CDP endpoint
Auto-Connect
Use --auto-connect to automatically discover and connect to a running Chrome instance without specifying a port:
# Auto-discover running Chrome with remote debugging
# Or via environment variable
AGENT_BROWSER_AUTO_CONNECT=1
Auto-connect discovers Chrome by:
- Reading Chrome's
DevToolsActivePortfile from the default user data directory - Falling back to probing common debugging ports (9222, 9229)
This is useful when:
- Chrome 144+ has remote debugging enabled via
chrome://inspect/#remote-debugging(which uses a dynamic port) - You want a zero-configuration connection to your existing browser
- You don't want to track which port Chrome is using
Streaming (Browser Preview)
Stream the browser viewport via WebSocket for live preview or "pair browsing" where a human can watch and interact alongside an AI agent.
Enable Streaming
Set the AGENT_BROWSER_STREAM_PORT environment variable:
AGENT_BROWSER_STREAM_PORT=9223
This starts a WebSocket server on the specified port that streams the browser viewport and accepts input events.
WebSocket Protocol
Connect to ws://localhost:9223 to receive frames and send input:
Receive frames:
Send mouse events:
Send keyboard events:
Send touch events:
Programmatic API
For advanced use, control streaming directly via the protocol:
import { BrowserManager } from 'agent-browser';
const browser = new BrowserManager();
await browser.launch({ headless: true });
await browser.navigate('https://example.com');
// Start screencast
await browser.startScreencast(
(frame) => {
// frame.data is base64-encoded image
// frame.metadata contains viewport info
console.log('Frame received:', frame.metadata.deviceWidth, 'x', frame.metadata.deviceHeight);
},
{
format: 'jpeg',
quality: 80,
maxWidth: 1280,
maxHeight: 720,
}
);
// Inject mouse events
await browser.injectMouseEvent({
type: 'mousePressed',
x: 100,
y: 200,
button: 'left',
});
// Inject keyboard events
await browser.injectKeyboardEvent({
type: 'keyDown',
key: 'Enter',
code: 'Enter',
});
// Stop when done
await browser.stopScreencast();
Architecture
agent-browser uses a client-daemon architecture:
- Rust CLI - Parses commands, communicates with daemon
- Rust Daemon - Pure Rust daemon using direct CDP, no Node.js required
The daemon starts automatically on first command and persists between commands for fast subsequent operations. To auto-shutdown the daemon after a period of inactivity, set AGENT_BROWSER_IDLE_TIMEOUT_MS (value in milliseconds). When set, the daemon closes the browser and exits after receiving no commands for the specified duration.
Browser Engine: Uses Chrome (from Chrome for Testing) by default. The --engine flag selects between chrome and lightpanda. Supported browsers: Chromium/Chrome (via CDP) and Safari (via WebDriver for iOS).
Platforms
| Platform | Binary |
|---|---|
| macOS ARM64 | Native Rust |
| macOS x64 | Native Rust |
| Linux ARM64 | Native Rust |
| Linux x64 | Native Rust |
| Windows x64 | Native Rust |
Usage with AI Agents
Just ask the agent
The simplest approach -- just tell your agent to use it:
Use agent-browser to test the login flow. Run agent-browser --help to see available commands.
The --help output is comprehensive and most agents can figure it out from there.
AI Coding Assistants (recommended)
Add the skill to your AI coding assistant for richer context:
This works with Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, Goose, OpenCode, and Windsurf. The skill is fetched from the repository, so it stays up to date automatically -- do not copy SKILL.md from node_modules as it will become stale.
Claude Code
Install as a Claude Code skill:
This adds the skill to .claude/skills/agent-browser/SKILL.md in your project. The skill teaches Claude Code the full agent-browser workflow, including the snapshot-ref interaction pattern, session management, and timeout handling.
AGENTS.md / CLAUDE.md
For more consistent results, add to your project or global instructions file:
Use `agent-browser` for web automation. Run `agent-browser --help` for all commands.
Core workflow:
1. 2.3.4.
Integrations
iOS Simulator
Control real Mobile Safari in the iOS Simulator for authentic mobile web testing. Requires macOS with Xcode.
Setup:
# Install Appium and XCUITest driver
Usage:
# List available iOS simulators
# Launch Safari on a specific device
# Same commands as desktop
# Mobile-specific commands
# Close session
Or use environment variables:
| Variable | Description |
|---|---|
AGENT_BROWSER_PROVIDER |
Set to ios to enable iOS mode |
AGENT_BROWSER_IOS_DEVICE |
Device name (e.g., "iPhone 16 Pro", "iPad Pro") |
AGENT_BROWSER_IOS_UDID |
Device UDID (alternative to device name) |
Supported devices: All iOS Simulators available in Xcode (iPhones, iPads), plus real iOS devices.
Note: The iOS provider boots the simulator, starts Appium, and controls Safari. First launch takes ~30-60 seconds; subsequent commands are fast.
Real Device Support
Appium also supports real iOS devices connected via USB. This requires additional one-time setup:
1. Get your device UDID:
# or
|
2. Sign WebDriverAgent (one-time):
# Open the WebDriverAgent Xcode project
In Xcode:
- Select the
WebDriverAgentRunnertarget - Go to Signing & Capabilities
- Select your Team (requires Apple Developer account, free tier works)
- Let Xcode manage signing automatically
3. Use with agent-browser:
# Connect device via USB, then:
# Or use the device name if unique
Real device notes:
- First run installs WebDriverAgent to the device (may require Trust prompt)
- Device must be unlocked and connected via USB
- Slightly slower initial connection than simulator
- Tests against real Safari performance and behavior
Browserless
Browserless provides cloud browser infrastructure with a Sessions API. Use it when running agent-browser in environments where a local browser isn't available.
To enable Browserless, use the -p flag:
Or use environment variables for CI/scripts:
Optional configuration via environment variables:
| Variable | Description | Default |
|---|---|---|
BROWSERLESS_API_URL |
Base API URL (for custom regions or self-hosted) | https://production-sfo.browserless.io |
BROWSERLESS_BROWSER_TYPE |
Type of browser to use (chromium or chrome) | chromium |
BROWSERLESS_TTL |
Session TTL in milliseconds | 300000 |
BROWSERLESS_STEALTH |
Enable stealth mode (true/false) |
true |
When enabled, agent-browser connects to a Browserless cloud session instead of launching a local browser. All commands work identically.
Get your API token from the Browserless Dashboard.
Browserbase
Browserbase provides remote browser infrastructure to make deployment of agentic browsing agents easy. Use it when running the agent-browser CLI in an environment where a local browser isn't feasible.
To enable Browserbase, use the -p flag:
Or use environment variables for CI/scripts:
When enabled, agent-browser connects to a Browserbase session instead of launching a local browser. All commands work identically.
Get your API key from the Browserbase Dashboard.
Browser Use
Browser Use provides cloud browser infrastructure for AI agents. Use it when running agent-browser in environments where a local browser isn't available (serverless, CI/CD, etc.).
To enable Browser Use, use the -p flag:
Or use environment variables for CI/scripts:
When enabled, agent-browser connects to a Browser Use cloud session instead of launching a local browser. All commands work identically.
Get your API key from the Browser Use Cloud Dashboard. Free credits are available to get started, with pay-as-you-go pricing after.
Kernel
Kernel provides cloud browser infrastructure for AI agents with features like stealth mode and persistent profiles.
To enable Kernel, use the -p flag:
Or use environment variables for CI/scripts:
Optional configuration via environment variables:
| Variable | Description | Default |
|---|---|---|
KERNEL_HEADLESS |
Run browser in headless mode (true/false) |
false |
KERNEL_STEALTH |
Enable stealth mode to avoid bot detection (true/false) |
true |
KERNEL_TIMEOUT_SECONDS |
Session timeout in seconds | 300 |
KERNEL_PROFILE_NAME |
Browser profile name for persistent cookies/logins (created if it doesn't exist) | (none) |
When enabled, agent-browser connects to a Kernel cloud session instead of launching a local browser. All commands work identically.
Profile Persistence: When KERNEL_PROFILE_NAME is set, the profile will be created if it doesn't already exist. Cookies, logins, and session data are automatically saved back to the profile when the browser session ends, making them available for future sessions.
Get your API key from the Kernel Dashboard.
License
Apache-2.0