Capture a Chrome

Run bmc in a folder to launch (or attach to) Chrome and stream its network traffic.

Run bmc in a folder to launch (or attach to) a Chrome instance and stream its network traffic into your dashboard feed.

A folder is a device

The directory you run bmc in is the device. On the first capture in a folder, bmc creates ./.bmc.json there — it holds the device's UUID and a 365-day device JWT, so capture never needs your user session again. Re-runs in the same folder reuse that device.

Because each folder is independent, you can run many devices on one machine — one per folder, each pointing at its own Chrome instance.

Start capturing

bash
bmc start "My Device"

The first run in a folder asks for a device name (the default is the folder name) or takes the one you pass. After that, ./.bmc.json exists, so the name is remembered. Pass a different name later to rename the device:

bash
bmc start "Renamed Device"

bmc start [name] and the bare bmc [name] form do the same thing:

bash
bmc "My Device"     # identical to: bmc start "My Device"

bmc with no arguments instead brings up the background daemon — so always pass a name (or start) when you mean to capture in the current folder.

Press Ctrl-C to stop. If bmc launched the Chrome itself, it shuts that Chrome down too; a Chrome you launched yourself is left running.

Launch vs. attach

By default, bmc launches its own Chrome — that's the only way it can apply your device's external proxy and any pass-through flags. The model is: one folder = one device = its own independent Chrome instance.

  • No --port (the usual case): bmc starts from this device's saved port, and if that's taken it auto-claims the next free debug port (9222 → 9223 → …). The chosen port is persisted to .bmc.json, so every folder keeps its own. It never attaches to a Chrome it didn't launch — including your everyday Chrome on 9222.
  • Explicit --port <p>: your call. If something is already serving CDP on that port, bmc attaches to it; otherwise it launches Chrome there.
bash
cd ~/work/app-a && bmc start "App A"     # e.g. its own Chrome on 9222
cd ~/work/app-b && bmc start "App B"     # e.g. its own Chrome on 9223

The Chrome profile

When bmc launches Chrome, the profile (--user-data-dir) defaults to the folder you ran bmc in — so it's local to the project and persists across runs. Override it with CDP_USER_DATA_DIR, or by passing -- --user-data-dir=… (see External proxy & custom Chrome).

Attach to your own Chrome

To drive a Chrome you started yourself, use bmc attach. It never launches Chrome — it attaches to an already-running one on the debug port, and if none is up yet, it waits for one to appear:

bash
# start Chrome yourself with remote debugging…
open -na "Google Chrome" --args --remote-debugging-port=9333 --user-data-dir=/tmp/c
# …then attach
bmc attach "Manual" --port 9333

Heads up: When attaching, bmc can't apply the device's external proxy or any -- <chrome-flags> — it didn't launch that Chrome, so those launch-time settings are ignored. You'll see a warning if either is configured.

What gets captured

bmc honors the same capture rules as every other device, all set in the dashboard and pushed live (no restart needed):

  • Only hosts in your SSL Proxying domain list are recorded — unless Inspect all requests is on (set per-device or globally).
  • Hosts in your ignore list are always dropped.

Captured requests stream to your dashboard feed tagged source: "cdp" with a Chrome badge. Everything else works for CDP devices too: breakpoints, HAR export, and the global Pause all requests toggle. Manage capture rules and per-device settings under Devices.

Tag a client

Stamp captured requests with an internal client label (shown as a dashboard badge, never sent upstream):

bash
bmc start "My Device" --client "checkout-service"
bmc start "My Device" --client ""        # clear the stored tag

The tag persists to .bmc.json. You can also set it with the CDP_CLIENT environment variable for a single run.

Next

Install & sign inNamed devices & the daemon