Browser Sessions

Browser sessions give you a real Chromium instance inside a dedicated microVM, exposed through a standard Chrome DevTools Protocol (CDP) endpoint. The browser is a genuine desktop Chrome installation — not headless-only, not a container-shared process.

Browser sessions can also load developer-supplied extensions through a dedicated upload API. See Browser Extensions.

Recommended client: rebrowser-puppeteer-core

We recommend rebrowser-puppeteer-core for driving Chaser browser sessions. It is a drop-in replacement for puppeteer-core — the API is identical, so existing Puppeteer code works without changes. We recommend it over both stock Puppeteer and Playwright for the following reason: Chaser’s Chromium is custom-patched at the C++ layer for stealth, and stock Puppeteer’s instrumentation hooks and Playwright’s lifecycle state machine both fight those patches in subtle ways. rebrowser-puppeteer-core avoids the instrumentation that conflicts with our patches, so behavior stays consistent with what the patched browser actually does.

Raw CDP clients are also fully supported — use them when you do not want a high-level wrapper at all.

Captcha solving

Chaser browser sessions automatically solve common captchas (including CAPTCHA challenges that interrupt automated flows). No configuration, no third-party API key, and no per-page wiring is required — the capability is built into the browser image. This is included on every browser session.

Create a browser session

$
# Targetless create (free tier: ephemeral, paid: default browser workspace)
$
chaser browser --json
$
$
# Force ephemeral
$
chaser browser --ephemeral --json
$
$
# Persistent (workspace-backed)
$
chaser workspaces create --session-type browser --name my-browser --json
$
chaser workspaces default set my-browser --browser
$
chaser browser --workspace my-browser --json

When you omit workspace, free-tier accounts launch disposable browsers while paid accounts reuse or bootstrap the default browser workspace for the active account.

Connect with rebrowser-puppeteer-core

$
npm i rebrowser-puppeteer-core

1
import puppeteer from "rebrowser-puppeteer-core";
2
3
const browser = await puppeteer.connect({
4
  browserWSEndpoint: "wss://<session_id>.chaser.sh/"
5
});
6
const page = await browser.newPage();
7
await page.goto("https://example.com");
8
console.log(await page.title());
9
await browser.close();

The API is identical to puppeteer-core, so any existing Puppeteer code works as-is once the import is updated. If you previously used Playwright’s chromium.connectOverCDP(...), port the snippet to the Puppeteer API above — we recommend rebrowser-puppeteer-core over Playwright for Chaser browser sessions.

CDP discovery endpoints

The session control URL supports standard CDP discovery routes:

• GET /json/version — browser version and WebSocket debugger URL
• GET /json/list — open tabs/targets
• GET /json/protocol — full CDP protocol definition

If you need the raw WebSocket URL for manual CDP clients, read webSocketDebuggerUrl from /json/version. The TypeScript SDK exposes the same value through client.browser.cdpWebSocketUrl(sessionId).

MCP browser tool

The browser MCP tool provides three actions:

$
# Discover available browser tools
$
curl -sS "$CHASER_API_URL/v1/mcp" \
>
  -H "Authorization: Bearer $CHASER_API_KEY" \
>
  -H "Content-Type: application/json" \
>
  -d '{
>
    "jsonrpc": "2.0", "id": 1,
>
    "method": "tools/call",
>
    "params": {
>
      "name": "browser",
>
      "arguments": {"session_id": "<session_id>", "action": "discover"}
>
    }
>
  }' | jq

Browser jobs

For queued browser work instead of direct CDP control, use the jobs API:

• browser.action — sequential CDP method calls
• browser.scrape — navigate to a URL and optionally extract content by selector

$
chaser jobs scrape <session_id> --url "https://example.com" --wait --json

See Jobs for details.

Proxy selection

Browser sessions accept an optional proxy selector to route traffic through residential or datacenter proxies. If omitted, the platform applies a default based on your billing plan.

Browser extension uploads

Browser sessions support extension-specific uploads through:

• POST /v1/sessions/{id}/browser/extensions
• POST /v1/sessions/{id}/browser/restart

This is separate from sandbox file transfer:

• sandbox sessions support generic upload and download
• browser sessions support extension bundle upload only

Use a workspace-backed browser session if you want uploaded extensions to persist across future boots.

$
curl -sS "$CHASER_API_URL/v1/sessions/<session_id>/browser/extensions" \
>
  -H "Authorization: Bearer $CHASER_API_KEY" \
>
  -F "bundle=@./my-extension.zip" \
>
  -F "restart_browser=true" | jq

See Browser Extensions for bundle format, persistence behavior, and restart details.

Stealth

Chaser browser sessions are designed to present as real desktop Chrome installations. Each session runs a genuine Chromium binary inside its own VM with a real display server, real system fonts, and standard browser fingerprints. The CDP proxy layer applies additional hardening to prevent common automation detection signals.

Stealth outcomes depend on your target sites and traffic patterns. Test against your specific targets for best results.