Integration feedback: Browser Use adapter capture fields

[aaronlab]

BrowserTrace has a basic Browser Use adapter through browsertrace.integrations.browser_use.attach_tracer. This issue collects feedback from Browser Use users before expanding it.

Guide:
https://aaronlab.github.io/browsertrace/browser-use-debugging.html

No-network callback demo:
examples/browser_use_callback_demo.py

Current adapter goal:

• Attach to a Browser Use agent step callback.
• Record a local timeline with screenshot, URL, action summary, model thought/actions, compact browser-state context, step status, and errors.
• Keep data local by default.
• Support browsertrace export --public for public-safe trace sharing that omits prompt/model I/O, screenshots, and URLs.

Feedback wanted:

• Which Browser Use fields are most useful at failure time?
• Should BrowserTrace capture task text, step number, memory, extracted page text, DOM snippets, selected element, retry state, or final result?
• Should screenshots be captured every step, only failed steps, or configurable?
• What should a failed Browser Use run look like in the timeline?
• Which Browser Use API versions or agent patterns should be tested first?

Proposed follow-up checklist:

• Add a no-network Browser Use-shaped adapter example.
• Add tests for richer Browser Use model input fields if the API exposes them.
• Document callback compatibility for current Browser Use releases.
• Add a small troubleshooting section to the Browser Use guide.

Please share real failure shapes, not stars/upvotes. A good report includes the Browser Use version, the failure mode, and what context was missing from your logs.

[aaronlab]

Added the Browser Use troubleshooting section to the guide in 221a9c8. It now covers:

• Could not attach to this Agent and the register_new_step_callback path
• missing screenshots in some Browser Use states
• using browsertrace export <run_id> --public -o public.html before public sharing

Local verification before push: uv run --python 3.11 --extra dev pytest -q -> 97 passed.

[aaronlab]

Added the callback compatibility section to the Browser Use guide in 570c25a. The guide now distinguishes:

• BrowserTrace-supported attach surfaces: register_new_step_callback, on_step_start, on_step, and _new_step_callback attributes
• Browser Use run-hook examples that pass on_step_start / on_step_end directly to agent.run(...)
• The current fallback for run-hook-only apps: use manual run.snapshot(...) and comment here with the version/hook shape needed

Local verification before push: uv run --python 3.11 --extra dev pytest -q -> 98 passed.

[aaronlab]

Implemented the richer Browser Use model input context in 154ce44. The adapter now stores a compact model_input payload with step count and browser-state fields such as URL, title, tabs, and whether a screenshot was captured. It does not inline screenshot data into model_input.

The checklist is now complete, but I am leaving the issue open as the Browser Use feedback thread for real failure shapes and version-specific hook reports.

Local verification before push: uv run --python 3.11 --extra dev pytest -q -> 99 passed.

[aaronlab]

Historical note (2026-05-11): this Browser Use update was written for v0.1.15; the feature remains available in the current PyPI release v0.1.16.
Current install path: pip install "browsertrace[ui]". Current release: https://github.com/aaronlab/browsertrace/releases/tag/v0.1.16.

Implemented Browser Use run-hook support in v0.1.15.\n\nWhat changed:\n\n- Added create_run_hooks(tracer, name=...) for Browser Use apps that pass on_step_start and on_step_end directly to agent.run(...).\n- The helper records available Browser Use history and browser-session summaries: latest thought, action, extracted content, URL, title, tabs, and screenshot flag.\n- Kept the existing attach_tracer(agent, ...) path for register_new_step_callback and compatible callback attributes.\n\nRelease: https://github.com/aaronlab/browsertrace/releases/tag/v0.1.15\nGuide: https://aaronlab.github.io/browsertrace/browser-use-debugging.html\n\nVerification before release:\n\n- Local targeted Browser Use tests: 8 passed.\n- Local metadata/docs release-link tests: passed.\n- Local full suite: 299 passed.\n- Local build: wheel and sdist built for 0.1.15.\n- twine check: passed for wheel and sdist.\n- Remote CI on main: success for Python 3.11, 3.12, 3.13, plus package build.\n- Remote Pages deploy: success.\n- Verified install from tag: uvx --from "browsertrace[ui] @ git+https://github.com/aaronlab/browsertrace@v0.1.15" browsertrace doctor/demo/list works.\n- Verified tag install exposes create_run_hooks.

[aaronlab]

Historical note (2026-05-11): this feedback thread was opened during the v0.1.15 Browser Use launch; v0.1.16 is now the current PyPI release.

Opened a Browser Use community feedback thread for the v0.1.15 run-hook path:\n\nhttps://github.com/browser-use/browser-use/discussions/4816\n\nThe post asks Browser Use users which failure fields matter most: task text, memory, extracted content, selected element, retry state, screenshots, model actions, final result, or other fields. It does not ask for stars or upvotes.

[aaronlab]

Community feedback update (2026-05-10): browser-use/browser-use#4639 produced a useful boundary confirmation for evidence import vs failure debugging.

External thread:
browser-use/browser-use#4639 (comment)

Follow-up guardrail added:
browser-use/browser-use#4639 (reply in thread)

Takeaway for this adapter: keep BrowserTrace's step-hook failure-debugging surface separate from post-run evidence reducers. If we add reducer/export helpers later, they should distinguish fields absent because they are outside the source boundary from fields present but empty/error, so users do not confuse intentionally omitted browser state with data loss.

[aaronlab]

Community feedback update (2026-05-10): posted a targeted technical reply in browser-use/browser-use#4742 about screenshot blobs poisoning LLM conversation history.

External thread:
browser-use/browser-use#4742 (comment)

Takeaway for the Browser Use adapter: keep screenshots and other large browser artifacts behind a durable artifact_id / path boundary, and pass pixels to the model only when a step actually needs a typed image content block. For normal trace/debug history, prefer small stable metadata such as dimensions, digest, status, and artifact id. This matches the BrowserTrace public export invariant: artifacts are for human debugging; model messages should carry the minimum representation needed for the next model call.

No stars, votes, reposts, or reciprocal promotion were requested.