Merge daemon + cdp-monitor into a single CDP-direct backend. All CLI
and MCP commands now route through the daemon HTTP API instead of
direct CDP connections or Extension relay.
Key changes:
- Daemon: rewrite to hold persistent CDP WebSocket, handle all 30+
commands via dispatchRequest, per-tab event state with RingBuffer,
short tab IDs (4-char hex), global seq counter, incremental queries
via since/cursor mechanism
- CLI: all commands route through daemon HTTP, --tab accepts string
short IDs, add --since/--method/--status flags for network queries,
fix tab close with --tab flag, fix invalid tab ID silent fallback
- MCP: tab parameter z.number() → z.string(), add browser_console
and browser_errors tools, add since/method/status/limit params to
browser_network, remove Extension dependency hints
- Shared: export additional types for daemon consumption
Bug fixes from harness testing:
- Invalid tab ID now errors instead of silent fallback
- tab_new works with zero existing tabs
- console.warn() correctly captured as type "warn"
- --tab flag works with tab close command
Closes#131
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
replMode: true caused Chrome to treat Promise values as plain objects,
bypassing awaitPromise: true. This made all async site adapters
(twitter/reply, twitter/search, etc.) return empty {} instead of
actual results.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Chrome Dev installs to %LOCALAPPDATA% on Windows, not Program Files.
Without these paths bb-browser falls through to Edge even when Chrome
Dev is installed.
Fixes feedback from @NormanMises_
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- #82: extract EXEC_TIMEOUT_BUFFER_MS constant for magic number 5000
- #91: remove failed tabs from sessionOpenedTabs to prevent stale entries
- #25: update platform/command counts from 35/97 to 36/103
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Add `background: true` to both `Target.createTarget` CDP calls so that
`bb-browser open --tab` and `bb-browser tab new` no longer activate the
Chrome window. This prevents disrupting the user's workflow when agents
run browser automation in the background.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
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>
Yanwu