Skip to content

Recording captures zero events: extension never loads (browser-use 0.13 / Chrome 137+) and schema validator 422s every WORKFLOW_UPDATE #165

Description

@Sangaibisi

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_step strips cssSelector from step params, but KeyPressActionModel & friends require cssSelector → every selector-based deterministic action fails validation.
  • Semantic key_press crashes on named keys: dict.get(key, {... ord(key.upper()) ...}) evaluates the default eagerly, so ord('ENTER') raises even though 'Enter' is in the map.
  • The hand-rolled Input.dispatchKeyEvent uses a stale CDP session (-32601 'Input.dispatchKeyEvent' wasn't found); page.press() works.
  • The key_press verifier requires the pressed element to still be visible — keys that navigate (Enter on a search box) always "fail" verification and get re-pressed.
  • cli.py crashes with NameError: llm_instance when BROWSER_USE_API_KEY is unset, and the FastAPI backend both imports Browser from the pre-0.13 path (browser_use.browser.browser) and instantiates ChatBrowserUse eagerly, so even the no-AI path 500s without an API key.

Environment

  • macOS 15 (arm64), Google Chrome 151 installed
  • Python 3.12, uv sync from workflows/pyproject.toml (browser-use==0.13.4)
  • Extension built from extension/ (wxt build output at extension/.output/chrome-mv3)

We have a PR with fixes for all of the above.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions