Monitoring commands (network, console, errors, trace) are broken in
direct CDP mode because each CLI invocation is a new short-lived
process that cannot accumulate events over time.
This introduces a long-running background monitor process that
maintains a persistent CDP connection and collects events:
- cdp-monitor-state.ts: MonitorState class extracted from cdp-client.ts
event handling logic (Network.*, Runtime.*, trace)
- cdp-monitor.ts: standalone Node.js process that connects to Chrome
via CDP, attaches to all page targets, and serves an HTTP API on
127.0.0.1 with bearer-token auth
- monitor-manager.ts: CLI-side lifecycle management (spawn, health
check, shutdown, command forwarding)
- client.ts: routes monitor actions (network/console/errors/trace)
through the monitor with graceful fallback to direct CDP
- tsup.config.ts: adds cdp-monitor as a build entry point
The monitor auto-discovers new tabs, writes PID/port/token files to
~/.bb-browser/, and auto-exits after 30 minutes of inactivity.
cdp-client.ts is intentionally left untouched to avoid regressions.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Add DOM.getDocument before DOM.performSearch in xpath fallback (fixes cross-process click/fill)
- Persist refs to /tmp/bb-browser-refs-<targetId>.json for cross-process usage
- Fix fill command: use backendNodeId for DOM.focus, add insertTextIntoNode helper
- Graceful snapshot fallback for complex pages (google.com)
All 13 core commands tested and passing.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Unref WebSocket so it doesn't keep the event loop alive
- Call process.exit(0) after main() resolves
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Major architecture change: remove dependency on Chrome extension and daemon.
bb-browser now manages its own Chrome instance with --remote-debugging-port
and connects directly via CDP WebSocket.
New files:
- cdp-client.ts: CDP WebSocket client, implements all actions directly
- cdp-discovery.ts: auto-discover CDP port (OpenClaw → managed Chrome → auto-launch)
- history-sqlite.ts: read browser history from SQLite (Chrome/Edge/Brave/Arc)
Key changes:
- Auto-launch managed Chrome at ~/.bb-browser/browser/ on port 19825
- User data persists (logins saved across sessions)
- SQLite history replaces chrome.history extension API
- site recommend reads from main Chrome's history (not managed instance)
- Flat CDP protocol support (Chrome 146+)
- --port flag for explicit CDP port override
- All actions implemented: eval, click, snapshot, network, console, frame, dialog, trace
Zero config setup: npm install -g bb-browser → just works
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Bump version to 0.7.0
- Fix VERSION constant in index.ts (was stuck at 0.3.0)
- On `site update`, check npm registry for newer version and show upgrade hint
- Only prompt when npm version is higher than current
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- `bb-browser star` — stars epiral/bb-browser and epiral/bb-sites via gh CLI
- Show hint after `site update` output to guide agents and users
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Run site adapters directly through OpenClaw's built-in Chrome browser,
without needing bb-browser's Chrome extension or daemon.
bb-browser site v2ex/hot --openclaw
bb-browser site zhihu/hot 3 --openclaw --jq '.items[].title'
The bridge (openclaw-bridge.ts, ~40 lines) uses `npx openclaw browser`
commands: tabs/open/evaluate. Adapter JS is passed directly via
execFileSync to avoid shell escaping issues.
Existing daemon-based flow is unchanged when --openclaw is not set.
Closes#28
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
ensureDaemonRunning() previously returned as soon as the daemon HTTP
server was ready, but the Chrome extension might not have connected
via SSE yet. This caused intermittent "extension not connected" (503)
or "Failed to fetch" errors on the first command.
Now polls /status for extensionConnected (up to 10s) after daemon
starts, ensuring the full CLI → daemon → extension pipeline is ready
before sending any command.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Spawn a detached `git pull --ff-only` in the background after each
site command. Non-blocking, no output, keeps community adapters fresh
without user intervention.
Closes#20
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Only show domains with >= 5 visits
- Exclude localhost and non-domain strings (e.g. Chrome extension IDs)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
New commands:
- `history search/domains` — query Chrome browsing history via chrome.history API
- `site recommend` — cross-reference history with adapters for personalized discovery
- `site info <name>` — expose full adapter @meta (args, example, domain)
- `--jq <expr>` — inline jq-like JSON filtering (inspired by gh CLI)
Agent UX improvements:
- --help grouped by intent, "开始使用" section first with site examples
- --help top hint explicitly guides Agents to use site commands over browser automation
- `open` command shows 💡 hint when the URL has available site adapters
- `--jq` auto-strips `.data.` prefix for Agent tolerance
- `site update` post-install nudge for site recommend
- AGENTS.md with full UX writing spec for contributors
Closes#21, closes#23, relates #24
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Group commands by function (site adapters, navigation, interaction,
page info, network/debug, daemon) instead of a flat list.
Move site adapter section to the top with usage examples, making
the most powerful feature immediately visible.
Closes#13
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
MCP server now sends instructions on connect so agents immediately
understand what bb-browser can do (capabilities, site adapters, etc).
New top-level `bb-browser guide` command teaches how to turn any
website into a site adapter — reverse engineer, write, test, contribute.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
reportHint now shows two options for agents:
1. gh issue create --repo epiral/bb-sites
2. bb-browser site github/issue-create epiral/bb-sites
Agents choose whichever tool is available.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
When a site adapter fails, include a reportHint field telling the
agent how to file an issue via `gh issue create --repo epiral/bb-sites`.
Agents decide themselves whether to use gh CLI or bb-browser's own
github site adapter.
Remove site report subcommand — agents handle reporting autonomously.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Check both error and hint fields for auth keywords.
When detected, replace with actionable login URL hint.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
When a site adapter returns 401/403/unauthorized errors, automatically
suggest the user to log in to the site's domain in their browser.
Works in both CLI and JSON output modes.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Show actionable setup guide when:
- Daemon not running (ECONNREFUSED)
- Extension not connected (HTTP 503)
Hints include install steps and GitHub releases link, guiding both
users and AI agents to complete the setup.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
`bb-browser --mcp` spawns the MCP server with stdio transport.
Users can configure AI tools with: npx -y bb-browser --mcp
Also fixes root tsup bundling to properly exclude ws while
bundling all other deps (MCP SDK, ajv, zod).
Bump version to 0.4.1.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
yan5xu