feat(browser): support scoped fetch proxy

[MagMueller]

Summary

• allow fetch-use to target a deployment-provided proxy endpoint
• authenticate that proxy with a scoped bearer capability instead of a Browser Use API key
• preserve the existing direct fetch service path
• treat direct-key and scoped-proxy modes as disjoint, failing closed when proxy configuration is incomplete

This is the BrowserCode half of the V4 integration. Cloud supplies the run-scoped proxy endpoint and its existing run capability. Upstream service credentials remain in the control plane. A partial proxy configuration cannot silently fall back to native HTTP, send a scoped capability to the default endpoint, or send a Browser Use API key to a custom endpoint.

All committed test credentials are explicit placeholders; no production values, user URLs, or session identifiers are included.

Validation

• focused fetch-use tests: 4 passed, 1 live test skipped without an API key
• package typecheck passed
• repository pre-push filtered typecheck: 16/16 packages passed with Bun 1.3.14
• git diff --check passed

[cubic-dev-ai]

All reported issues were addressed across 2 files (changes from recent commits).

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[Alezander9]

Thanks Magnus — the design is reasonable but this can't land yet, and there are a couple of things to settle first.

The path is inert in v4 today

Three independent gates, all currently closed:

1. Cloud sets neither BROWSER_USE_FETCH_URL nor BROWSER_USE_FETCH_TOKEN for the bcode process (the env dict is backend/sandboxes/v4-worker/app.py:1920-1939).
2. webfetch.ts:59 requires experimental.fetch_use === true in config. The generated .bcode/bcode.json (app.py:1468-1479) doesn't set it.
3. The prompt explicitly says "Never call webfetch to inspect a URL the user wanted you to visit" (app.py:1143).

So merging this changes no behavior anywhere, which means it also can't be validated anywhere. We'd rather land the cloud half and the bcode half together so there's an end-to-end path to test.

Env naming forks our existing convention

Cloud already uses FETCH_USE_URL for this exact service on the v2/v3 sandbox path — backend/docker-compose.yaml:68, backend/sandboxes/bu-agent/entrypoint.py:1644, proxied by backend/control_plane/api/fetch/router.py:51. Introducing BROWSER_USE_FETCH_URL alongside it gives us two names for one thing. Please reuse the existing one.

enabled fails late rather than closed

enabled: hasProxySetting || directEnabled

A partially-configured proxy (URL set, token missing) reports enabled: true, so webfetch selects this route, and only then fails inside fetch with "fetch-use credentials are missing or partially configured". The PR description says the intent is to fail closed; as written it fails late, at call time, after the routing decision is already made. If the config is incomplete, enabled should be false and the layer should log once at construction.

What would make this mergeable

• One env var name, matching FETCH_USE_URL.
• enabled false on incomplete config.
• The cloud side landed in the same window: the env vars set in app.py:1920-1939, and experimental.fetch_use in the generated bcode.json — plus a decision on whether the "never use webfetch" prompt rule should be relaxed, since otherwise the agent still won't take this path.

Closing for now. Reopen or send a new PR once the cloud side is ready and we can test the whole route.