fix(browser): named browser_exec sessions compose with every backend - #86916
Merged
Conversation
session=<name> previously set BU_NAME and then skipped backend resolution entirely — the parameter was documented as cloud-only, so all local/CDP work funneled through the single default daemon and one IPC socket, and concurrent sessions (parallel subagents, simultaneous chats) clobbered each other's browser connection. Reported by @shantanugoel on X. Now a named session composes with whatever browser source is configured: - BU_NAME still namespaces the harness daemon (per-name IPC socket, log, pid — upstream already isolates these), for local Chrome and CDP. - The /browser connect CDP override is now exported for named sessions too; previously a named daemon ignored it and fell back to scanning local Chrome profiles. - On provider backends (Browserbase, Firecrawl, Nous gateway), the name keys its own provider browser via the shared _get_session_info cache (bu-named-<name>), so each name gets its own cloud browser, the same name reuses one across calls and tasks, and unnamed calls keep the per-task key. - Direct-API Browser Use cloud configs keep the native named-daemon path (provider resolution would double-session and double-bill). Tool schema/description updated so models reach for session=<name> for parallel work on any backend, not just cloud. E2E: two named sessions against a real headless Chrome (real browser-use CLI, BU_CDP_URL) ran concurrently, set distinct page state, and read it back intact; sabotage run confirms the new tests fail without the fix.
Contributor
૮ >ﻌ< ა ci reviewran on fb8a4ae — fix(browser): named browser_exec sessions compose with every
|
alt-glitch
added
type/bug
teknium1
added a commit
that referenced
this pull request
Aug 15, 2026
Follow-up to #86916. That fix gave named sessions their own daemon (socket/log/pid) and their own provider browser — but on a SHARED local Chrome / CDP browser, a fresh named daemon still attaches to the first existing page, the same page a sibling daemon may hold. A named session that never calls new_tab() could still stomp another's tab. browser_exec now prepends a small preamble to the model's code for named sessions on shared browsers: once per daemon process (marker keyed by uid + BU_NAME + daemon pid), it creates a fresh tab via Target.createTarget and switch_tab()s onto it before any model code runs. Private per-name browsers (provider-keyed bu-named-<name>, or direct-API Browser Use cloud) skip the preamble via an internal env sentinel popped before launch — there's nobody to collide with, and the extra tab would leak. Best-effort by design: if the preamble's CDP calls fail, behavior degrades to pre-fix, never blocks the exec. E2E against a shared headless Chrome with the STOCK harness: two named sessions issuing bare js() writes (no new_tab) kept distinct state (EDGE-A/EDGE-B read back intact); the sabotage run without the preamble reproduced the clobber (both read EDGE-B). Removes the dependency on the upstream browser-harness tab-isolation PR for correctness.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
browser_execnamed sessions (session=<name>) now isolate concurrent browser work on every backend, not just Browser Use cloud — parallel subagents and simultaneous chats stop clobbering one shared daemon socket. Root cause: the tool setBU_NAMEand then skipped backend resolution entirely, so the name was cloud-only and all local/CDP traffic funneled through the single default daemon. Reported by @shantanugoel on X.Changes
tools/browser_use_cli.py: named sessions compose with_resolve_backend_cdpinstead of bypassing it. BU_NAME keeps namespacing the harness daemon (upstream already isolates socket/log/pid per name); the/browser connectCDP override is now honored by named sessions; on provider backends (Browserbase, Firecrawl, Nous gateway) the name keys its own provider browser through the shared_get_session_infocache (bu-named-<name>— same name reuses one browser across calls/tasks, different names never collide). Direct-API Browser Use cloud keeps the native named-daemon path (provider resolution would double-session and double-bill).session=<name>is presented as the isolation mechanism for parallel work on any backend.tests/tools/test_browser_use_cli.py: 3 new tests (compose-with-provider, name-stable-across-tasks, direct-API-BU-still-skips); removed the test pinning the old skip behavior.website/docs/user-guide/features/browser.md: concurrent-sessions paragraph.Validation
bu-named-<name>/browser connectoverridetests/tools/test_browser_use_cli.pyUpstream note: full tab-level isolation of multiple named local daemons on one Chrome additionally needs the harness to create a per-name tab instead of attaching to the first page — being submitted to browser-use/browser-harness separately (their issues #375/#582/#604 track the same cluster).
Infographic