# 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 채팅. 브라우저 생성, URL 열기, 점검 실행을 부탁하세요 — 동작은 확인 게이트를 거치고, 답변은 실제 캐처에 기반합니다.
다시는 손댈 일 없음
데몬은 유휴 시간에 스스로 업데이트하고, 라이브 빌드를 보고하며, 대시보드나 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는 Chrome, Brave, Edge와 함께 bmc의 내장 프로필 중 하나이며 — --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.