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>
Thanks for the clean fix! 🎉 The tsup `define` approach is exactly the right way to handle this.
Quick question: do you have any other suggestions for build/release automation? Things like auto-generating changelogs, version bumping workflows, or CI checks that could prevent this kind of drift in the future? I'm not very familiar with this area and would appreciate any recommendations.
- 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>
- OpenClaw section before Chrome Extension (no extension needed)
- Link to ClawHub skill bb-browser-openclaw
- Chrome Extension renamed to "standalone mode"
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Yanwu