# macOS / Linux (self-updates from the dashboard):
curl -fsSL https://cdp.busymate.net/install.sh | bash
# Sign in once, create a browser, and capture it → your Busymate feed:
bmc login
bmc create dev --browser chrome --start# Windows (PowerShell) — same, self-updating:
irm https://cdp.busymate.net/install.ps1 | iex
bmc login
bmc create dev --browser chrome --startThe simplest
从“打开 Chrome”到“检查每个请求”的最快路径——它还能塑造这些流量。
零信任配置——字面意义上的零
因为 bmc 直接接入 DevTools 协议，流量本就是解密后的。不碰钥匙串，不弹警告；Chrome 一启动，抓包就开始。
具名浏览器设备
后台守护进程把独立的 Chrome 配置文件管理成具名设备——从终端、仪表盘或一次 MCP 调用启动、停止、脚本化每一个。你的浏览器成为船队成员。
本地模拟与改写
驱动代理的同一个沙箱 JS 引擎运行在你真实的 Chrome 会话上：改写请求、合成响应，看着每个改动清晰地落入流量面板。
终端里的 BusyBro
一个带原生回滚的 REPL 聊天，熟知这台机器的设备。让它创建浏览器、打开网址、跑一项检查——操作需确认，答案基于你实际的抓包。
从此不用再碰它
守护进程空闲时自动更新，实时上报版本，并可从仪表盘或 MCP 远程重启。这是会自我维护的基础设施。
Reads Chrome traffic
bmc attaches to Chrome over the DevTools Protocol — the same wire DevTools itself uses — so it sees requests exactly as the browser does: already decrypted.
- 01
Its own Chrome, per folder
bmc start launches a dedicated Chrome with its own profile and its own debug port for the current directory. Each folder is an independent device — run it in two folders and you get two fully separate browsers.
- 02
Attach over the DevTools Protocol
It connects to Chrome's debug port over a WebSocket, auto-attaches to every tab, and enables the Network domain — the same wire Chrome DevTools itself uses. No extension, no proxy in the path, nothing injected into pages.
- 03
Events become entries
Request, response and timing events are correlated into the same entry shape every Busymate source uses, with headers and bodies (up to 1 MB per body) pulled straight from the browser — after Chrome already decrypted them.
- 04
Batched into one feed
Entries are batched and posted to the ingest API about once a second. The folder pairs as a real Busymate device, so its traffic lands in the same dashboard, the same filters, the same MCP tools and the same HAR export as every phone.
Capture without
TLS terminates inside Chrome, and bmc reads on the browser's side of it. There is no man-in-the-middle to trust — so there is nothing to install, and nothing for pinning to detect.
A proxy debugger decrypts HTTPS by re-signing it with its own certificate authority — which means installing that CA, trusting it in a keychain, and losing the apps that pin their certificates. bmc skips the whole problem: the DevTools Protocol hands over each request after Chrome has already decrypted it.
| What it takes | bmc (CDP) | Proxy (MITM) | iOS / Android app |
|---|---|---|---|
| Root CA to install | None | Yes — trust the proxy CA | Yes — on-device CA, decrypting only domains you opt in |
| Network setup | None | Point each client at the proxy | None — an on-device VPN tunnel |
| Pinned certificates | Unaffected — nothing sits in the TLS path | Pinned apps refuse the proxy CA | Pinned apps stay encrypted (metadata still visible) |
| What it sees | The Chrome it launches — every tab | Any app or script you point at it | Every app on the phone |
| Best for | Web apps, SPAs, agent-driven browsing | Backends, scripts, browsers on other machines | Mobile apps, in the field |
Each path is first-class: the proxy and the phone apps exist precisely for the traffic CDP can't see. Use bmc for browsers, the proxy for anything you can point at it, and the apps for whole-phone capture.
Drive the browser.
Every bmc browser is remote-controllable over MCP — an AI agent or a script can open pages, read them and act, while capture records every request the session makes. That combination is the point.
Drive and read the page
- browser_open
- Navigate the browser to a URL.
- browser_targets
- List the open tabs and pick the one to drive.
- browser_snapshot
- A compact accessibility-tree snapshot — the page as structured text, built for agents.
- browser_screenshot
- A PNG of the active page.
- browser_eval
- Run JavaScript in the page. Placeholder variables are resolved server-side from the device's env, so an agent can fill a login form without ever seeing the password.
- browser_cdp
- Raw DevTools Protocol access for everything else — owner-gated.
Browser profiles
Built-in Chrome, Brave and Edge profiles plus custom ones authored once in the dashboard — per-OS binaries, default flags and a flag catalog every machine's bmc resolves the same way.
- list_browser_profiles
- get_browser_profile
- upsert_browser_profile
- delete_browser_profile
The daemon, remotely
Live build, uptime and logs without SSH; list every named browser on a machine; restart or hot-update the daemon while running captures keep capturing. One switch arms or disarms it all, per device.
- get_cdp_daemon_status
- get_cdp_logs
- list_cdp_instances
- restart_cdp_daemon
- update_cdp_daemon
- set_device_cdp_control
Remote control is opt-in per device and permission-gated; capture keeps flowing either way.
一致的设备身份,
GodBrowser 是一款反指纹 Chromium,为浏览器赋予一致、看起来真实的设备身份。它是 bmc 内置的浏览器配置——因此智能体可以运行一个人设,并在与你手机相同的实时流中捕获其流量。
用一个参数选择 GodBrowser,bmc 就会像驱动任何其他浏览器设备一样,通过同一个 DevTools Protocol 驱动它:它检查该人设发出的每个请求——已解密、无根 CA、无代理——并将其流式发送到你的 Busymate 流。GodBrowser 正是为这种组合,将 bmc 宣传为其请求检查搭档。
浑然一体的单一身份
user-agent、屏幕、WebGL、canvas 与音频、区域设置和时区都与该人设一致——而 TLS/JA4、UA-CH 和编解码器在任何一行 JavaScript 运行之前就已对齐到所声明的设备。用 GodBrowser 自己的说法:一台真实设备,而非伪装的设备。
确定性种子
--bot-profile 参数从一个种子字符串派生出完整的设备身份。换种子即换设备——可重复、可复现,因此一个人设能被精确重放。
跨平台与浏览器的人设
Windows、macOS、Linux、iOS 和 Android 与 Chrome、Safari、Firefox、Samsung Internet 和 Edge 交叉组合,通过 --bot-os 和 --bot-browser 选择。其底座是打过补丁的 Chromium 151。
集群、API 与 MCP
GodBrowser 在你自己的节点集群上运行,可从代码、它的 API 或某个 AI 客户端驱动——并自带远程 MCP 服务器。代理按配置确定性分配;会话通过 Redis 在多台机器间同步。
# GodBrowser is a built-in bmc browser profile — pick it per device:
bmc create ios-persona --browser godbrowser -- \
--bot-os=ios --bot-browser=safari --bot-profile=seed-42 --startGodBrowser 是 bmc 的内置配置之一,与 Chrome、Brave 和 Edge 并列——用 --browser godbrowser 选中它就是全部设置。bmc 解析其二进制文件,暴露其人设参数,将设备配对为独立的 “God Browser”,并把捕获的流量标记为 gdp,使其在流中一目了然。不会向 GodBrowser 注入任何东西:bmc 通过 DevTools Protocol 驱动它,而其反指纹层位于浏览器内核,因此在自动化下保持完好。两款工具都原生支持 MCP——GodBrowser 的远程 MCP 服务器与 Busymate 的服务器,让同一个智能体能在一次会话中驱动人设并读取其流量,各自都在基于同意的令牌之后。
One tool,
Agent-driven QA
An assistant opens your staging site, walks the flow and screenshots what it sees — while the network feed shows exactly what broke, with full request and response bodies.
Debug a SPA
Watch XHR and fetch calls stream live with headers, bodies and timings while you click through the app. The history survives a reload — no DevTools-tab archaeology.
Capture an OAuth flow
Redirect chains, tokens and callbacks recorded end to end — including on providers whose pinned certificates a proxy can't open.
Work a signed-in page
The folder's Chrome profile keeps its session between runs; snapshot and eval read the page while capture documents every request behind it.
The sceptical
Does bmc need a certificate or a proxy?
No. It attaches to Chrome over the DevTools Protocol and reads traffic after Chrome has decrypted it. There is no root CA to install, no keychain trust prompt, and no proxy settings to change.
Does it work with certificate pinning and HSTS?
Yes. Pinning defends the TLS connection between Chrome and the server — bmc never touches that connection; it reads inside the browser. HSTS, corporate device policy and managed keychains are equally unaffected.
Does it modify pages or the sites I visit?
Capture injects nothing — bmc listens to Chrome's own network events. It also launches its own Chrome with its own profile, so your everyday browser is never touched.
Can it run headless or in CI?
Yes. Anything after -- goes straight to Chrome (for example --headless=new), and CDP_USER_JWT or CDP_PAIR_EMAIL and CDP_PAIR_PASSWORD sign in without opening a browser.
Which browsers does it support?
Chromium-family browsers: built-in Chrome, Brave, Edge and Chromium profiles, plus custom profiles you author in the dashboard. Anything that speaks the DevTools Protocol.
What about traffic outside the browser?
bmc only sees the Chrome it is attached to. For backends and scripts use the Busymate proxy; for whole-phone capture use the iOS or Android app — everything lands in the same feed.