Repository navigation
Description
Summary
On a fresh clone (main @ 891267b) with browser-use 0.13.4 pinned by pyproject.toml, python cli.py create-workflow / create-workflow-no-ai captures zero events: the browser opens, the user records, but the recording server never receives a single WORKFLOW_UPDATE, and after closing the browser the CLI hangs forever (the finalizer silently does nothing when last_workflow_update_event is None).
We debugged this end-to-end on macOS (arm64, Google Chrome 151) and found three independent causes:
1. browser-use's default extensions override --load-extension
RecordingService passes --load-extension=<repo>/extension/.output/chrome-mv3 via profile args, but browser-use appends its own --load-extension=<its three default extensions> afterwards. Chrome only honors the last occurrence of the flag, so the recorder extension is silently dropped. Verified via ps: the launched Chrome's command line contains only browser-use's extensions in --load-extension.
2. Branded Google Chrome 137+ ignores --load-extension entirely
Even with (1) fixed, browser-use launches the installed branded Google Chrome, which removed --load-extension support in 137+. The extension never loads (no service_worker target in /json on the debug port). Works fine with Playwright's Chromium / Chrome for Testing.
3. The schema validator rejects every incremental recording update
WorkflowDefinitionSchema.validate_ends_with_extract requires the last step to be extract/extract_page_content. The extension streams WORKFLOW_UPDATE events step-by-step while the user records, so essentially every update ends in click/input/navigation and the recording server responds 422 to all of them:
{"detail":[{"type":"value_error","loc":["body","HttpWorkflowUpdateEvent","payload","steps"],
"msg":"Value error, Workflow must end with an extract step ..."}]}
Even with the extension loading correctly, recording can never produce data unless the user happens to add an extraction step from the side panel.
Additional replay breakage found on the way
While validating the fix we also hit these in deterministic replay (details in the linked PR):
_run_deterministic_stepstripscssSelectorfrom step params, butKeyPressActionModel& friends requirecssSelector→ every selector-based deterministic action fails validation.- Semantic
key_presscrashes on named keys:dict.get(key, {... ord(key.upper()) ...})evaluates the default eagerly, soord('ENTER')raises even though'Enter'is in the map. - The hand-rolled
Input.dispatchKeyEventuses a stale CDP session (-32601 'Input.dispatchKeyEvent' wasn't found);page.press()works. - The
key_pressverifier requires the pressed element to still be visible — keys that navigate (Enter on a search box) always "fail" verification and get re-pressed. cli.pycrashes withNameError: llm_instancewhenBROWSER_USE_API_KEYis unset, and the FastAPI backend both importsBrowserfrom the pre-0.13 path (browser_use.browser.browser) and instantiatesChatBrowserUseeagerly, so even the no-AI path 500s without an API key.
Environment
- macOS 15 (arm64), Google Chrome 151 installed
- Python 3.12,
uv syncfromworkflows/pyproject.toml(browser-use==0.13.4) - Extension built from
extension/(wxt build output atextension/.output/chrome-mv3)
We have a PR with fixes for all of the above.
Activity