- Add new `extract_data` action that uses CSS selectors (querySelectorAll) to
extract structured data directly from the page without LLM cost. Supports
extracting text, href, src, or any HTML attribute from matching elements.
Returns structured JSON and optionally saves to CSV/JSONL/JSON files.
- Add `save_to_file` parameter to existing `extract` action so LLM-extracted
content can be written directly to a file instead of consuming context window
tokens. Enables accumulating data across multiple pages.
- Update both system prompts with a new `<data_extraction>` section that guides
the agent on when to use extract_data vs extract vs evaluate, and documents
the multi-page extraction pattern (extract → click Next → extract → repeat
with save_to_file appending to same file).
These changes address the core data extraction inefficiency where the agent was
forced to output all extracted tokens through the LLM, making bulk extraction
(100+ items, multi-page scraping) slow and expensive.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
When evaluate or extract returns results longer than MAX_MEMORY_LENGTH,
the full data is placed in extracted_content (shown only once via
read_state) and long_term_memory gets a useless summary. This causes
the agent to lose access to the data in later steps and hallucinate
placeholder text like "JSON_STRING_FROM_STEP_6".
Increasing the threshold 10x means most real-world results will stay
in long_term_memory and persist across steps.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Add 0-byte file check in upload_file handler to catch empty files early
with a clear error message instead of silently passing them to websites
- Add 0-byte file check in CDP upload watchdog before setFileInputFiles
to prevent uploading empty files that cause cascading failures
- Replace hardcoded text extension list in read_file_structured() with
dynamic derivation from _file_types, so new text-based file types
are automatically supported for external file reading
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Production data analysis (24h) shows:
- 36.5% of consecutive failures are AsyncIO CancelledError in browser state retrieval
- Complex pages can take 30-60s for DOM extraction + 30-60s for LLM call
- 120s was too tight for complex pages with slow network
180s (3 min) gives ~50% more buffer while still catching stuck steps.
This is the per-step timeout, not the total task timeout.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Based on production data analysis showing:
- gemini-3-pro-preview has 48% timeout rate with median 23s/step
- browser-use-2.0 timeout tasks have 74% slower time per step (10.7s vs 6.0s)
- Most timeouts occur on steps 11-20 where tasks are making progress
The 45s default was too aggressive. 75s provides ~3x the median step time
as buffer while still catching genuinely stuck tasks.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This prevents conflicts when switching between browser modes. Session parameters
(browser mode, cdp_url, etc.) are set at creation time and cannot be changed.
Without this fix, an existing 'default' session using chromium mode would be
silently reused when the user specifies --cdp-url, causing the CDP connection
to be ignored.
The same issue would occur switching between any browser modes (e.g., --browser
chromium to --browser real), but CDP is the most common case where users expect
to connect to a specific existing browser instance.
The session remap is placed early in main() before any command handling (server,
sessions, close --all) so those commands also target the correct session.
Users can still override with explicit --session flag if needed.
uses CDP Runtime.evaluate with includeCommandLineAPI to access getEventListeners() and mark elements with click/mousedown/pointerdown listeners before DOM snapshot capture
This adds support for connecting to an existing browser instance via
Chrome DevTools Protocol (CDP) URL in the skill_cli commands.
## Why
The current skill_cli only supports three browser modes:
- chromium: Launches a new Playwright-managed Chromium
- real: Launches users Chrome with profile
- remote: Uses Browser-Use Cloud
However, many use cases require connecting to an already-running browser:
- Remote browser automation via SSH tunnels
- Connecting to browsers in Docker containers
- Reusing authenticated browser sessions
- Integration with Claude Code on remote servers
The BrowserSession class already supports cdp_url, but it was not
exposed through the skill_cli. The TUI mode has this option, but the
simple CLI commands did not.
## Changes
- main.py: Added --cdp-url argument and pass-through to server
- server.py: Accept and store cdp_url, pass to session registry
- sessions.py: Handle cdp_url in session creation (takes precedence)
## Usage
browser-use --cdp-url http://localhost:9222 open https://example.com
browser-use --cdp-url http://localhost:9222 state
browser-use --cdp-url http://localhost:9222 click 5
## Testing
Tested with Chrome remote debugging over SSH tunnel - successfully
controlled a local macOS Chrome browser from a remote Linux server.
Vibe coded with Claude Opus 4.5
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
The CLI 'run' command now supports BROWSER_USE_API_KEY as an LLM option,
using ChatBrowserUse which is optimized for browser automation tasks.
This aligns the CLI behavior with the documented supported models at
https://docs.browser-use.com/supported-models which shows ChatBrowserUse
as a valid LLM option using BROWSER_USE_API_KEY.
Changes:
- Add ChatBrowserUse as first LLM option in get_llm() when BROWSER_USE_API_KEY is set
- Update error message to mention BROWSER_USE_API_KEY