feat(harness): add WebBrain extension agent - #273
Conversation
|
Thanks for the PR. I'll look into this. 🙌 |
Perry2004
left a comment
There was a problem hiding this comment.
Hi @alectimison-maker, thanks for the PR!
I reviewed the new integration and found a couple of issues:
- The agent seems to be stuck on the initial
about:blankpage and is unable to perform any actions. - The stop reason is reported incorrectly. A run in which no request is intercepted is classified as
"stop_reason": "eval_matched".
{
"intercepted": false,
"stop_reason": "eval_matched",
"stop_description": "Session stopped: eval_matched.",
"request": null,
"schema": {
"url_pattern": "https://never-match.invalid/",
"method": "GET"
}
}To reproduce:
- Create a dummy task:
{
"instruction": "Go to Google Search and search for clawench. Do not click any search results.",
"eval_schema": {
"url_pattern": "https://never-match.invalid/",
"method": "GET"
},
"time_limit": 2
}- Run the new WebBrain harness.
I suspect the stalling may be caused by a permission/consent/mode issue, as the extension's settings page opens when the agent starts and when I manually install the extension on a new profile it needs me to conscent a few things and select the mode:
{
"type": "pageLoad",
"timestamp": 1785794425648,
"url": "chrome-extension://opnkcadpbfggglmiofmahfblhlghklob/src/ui/settings.html",
"title": "WebBrain Settings"
}I'm not familiar with this agent, so my suspicions may be incorrect. Please let me know if you're able to reproduce and resolve these issues.
|
Thanks for the detailed reproduction. I was able to trace and address both issues in f8e6d8f:
I added regressions for the storage configuration and all three stop-classification cases (missing/false/true, plus invalid JSON). Revalidated the current head with:
A live container/model-backed run still requires the repository CI environment because this local host has no Docker/Podman engine or model credentials. |
|
Thanks for the changes! I'll re-review it in a bit. |
Perry2004
left a comment
There was a problem hiding this comment.
Thanks for the changes, this time it is very close to a complete integration, other than a few small issues.
- The agent error stop reason is not recorded in
results.py. - When the run is intercepted by the interception, the
agent-messagesonly contain the initial user input. - In
run-meta.json, therun_metrics.usage.statusshowsusage_unavailablewith all 0 values.
I think both issues are somewhere in run-webbrain-agent.py since that's the transcript & usage recording happens though I might be wrong.
For non-intercepted runs, I believe the agent-messages are recorded correctly, so might be the SIGTERM handling issue.
To reproduce, you may use this dummy task:
{
"instruction": "Open https://httpbin.org/forms/post. Fill the customer name with Clawbench User, set telephone to 1234567, set email to clawbench@example.com, choose Medium pizza size, check the Bacon topping, and submit the order. Stop after submitting.",
"eval_schema": {
"url_pattern": "https://httpbin\\.org/post(?:[?#].*)?$",
"method": "POST"
},
"time_limit": 4
}| if [ "$AGENT_STATUS" -eq 0 ]; then | ||
| STOP_REASON="agent_exited" | ||
| else | ||
| STOP_REASON="agent_error" |
There was a problem hiding this comment.
The new agent_error reason is not included in
ClawBench/src/clawbench/runner/run_support/results.py
Lines 12 to 23 in f6cbb85
It'd be great to change it to
webbrain_failed and record in results.py.
What does this PR do?
Adds a
webbrainharness that evaluates the pinnedWebBrain MV3 browser extension on ClawBench tasks.
The harness:
openai-completionsmodel config into WebBrain's persisted provider contract;background/chatextension interface through CDP;usage into ClawBench's standard data artifacts; and
lifecycle without changing other harnesses.
Motivation and design
ClawBench currently covers CLI, framework, and bridged extension agents, but it cannot evaluate a
self-contained browser-extension agent through the same corpus and five-layer recording pipeline.
The existing
EXTRA_LOAD_EXTENSIONSseam and data-driven harness registry make a dedicated adaptersmaller than introducing a new generic protocol.
WebBrain is pinned to commit
7b2357502da03d931117404bb89a60006bc3fa97; its source is loadedunpacked and no WebBrain repository scripts or dependencies run during the image build. The driver
uses the base runtime's existing
websocket-clientdependency, so the harness adds no Pythonpackage dependency.
Unattended runs use WebBrain's supported Instant clarification setting rather than patching its
safety logic. The benchmark instruction is the user request, while ClawBench's interceptor remains
the final boundary for consequential network submissions.
Corpus
Test plan
uv run --frozen pytest tests -q— 166 passeduv run --frozen ruff check .— passeduv run --frozen ruff format --check .— passeduv run --frozen pyright src/clawbench tests— passedbash -n src/clawbench/runtime/harnesses/webbrain/{setup-webbrain.sh,run-webbrain.sh}— passeduv buildplustwine checkand wheel-content inspection — passedin the development environment; the changed-harness CI job exercises the real Docker build.
Compatibility and risks
api_type: openai-completions; unsupported modes/types failbefore a model request.
api_keyscurrently selects its first entry rather than rotating keys.stays text/tool-only to avoid sending image blocks to incompatible endpoints.
price_unavailable; token counts are preserved from WebBrain trace usage.engine and model credentials.
Related issues
Closes #272