You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Concurrent agents share a single browser window, causing interference #62
When multiple agents are active at the same time, they all control the same
browser window. There's no isolation between sessions, so one agent's actions
disrupt another's in-progress task.
Current behavior
All agents target the one shared browser window.
When Agent B issues a command (navigate, click, type), it acts on the window
Agent A is mid-task in.
Agent A's state is clobbered — page navigated away, focus lost, refs
invalidated — and its task fails or produces wrong results.
Expected behavior
Each agent should operate against its own isolated browser context so concurrent
work doesn't collide. Also the browser windows should spawn in the same workspace as the agent running it
Impact
Agents silently corrupt each other's work; failures are hard to trace back to
the real cause (a different agent moved the page).
Makes any parallel/multi-agent browser workflow unreliable.
Fixed in v0.12.0 🎉 — thanks for the clear write-up, this was exactly the right root cause.
The problem was a single shared CDP connection: whichever browser pane attached last "owned" the Chrome DevTools debugger, so a second agent's wmux browser commands would steal the connection and act on the first agent's page.
What changed:
The CDP bridge is now multi-target — every browser pane keeps its own independent debugger attachment and accessibility ref map. No more stealing.
Each caller (an agent's terminal, via WMUX_SURFACE_ID, which the CLI now sends with every browser.* command) is bound to its own browser surface, created in that caller's workspace — addressing both asks in your issue. A second agent that finds the first's browser already owned spins up its own instead of colliding.
Manual (human) wmux browser use is unchanged — with no agent caller it falls back to the shared browser as before.
So two agents running browser tasks concurrently now each drive a separate, isolated browser pane in their own workspace. Available in the v0.12.0 zip on the releases page (right-click → Unblock after download). Let me know how it holds up in your multi-agent runs!
Activity
feat(#60,#62): WSL env/cwd support + per-agent browser isolation
amirlehmam commentedon Jun 26, 2026
Fixed in v0.12.0 🎉 — thanks for the clear write-up, this was exactly the right root cause.
The problem was a single shared CDP connection: whichever browser pane attached last "owned" the Chrome DevTools debugger, so a second agent's
wmux browsercommands would steal the connection and act on the first agent's page.What changed:
WMUX_SURFACE_ID, which the CLI now sends with everybrowser.*command) is bound to its own browser surface, created in that caller's workspace — addressing both asks in your issue. A second agent that finds the first's browser already owned spins up its own instead of colliding.wmux browseruse is unchanged — with no agent caller it falls back to the shared browser as before.So two agents running browser tasks concurrently now each drive a separate, isolated browser pane in their own workspace. Available in the v0.12.0 zip on the releases page (right-click → Unblock after download). Let me know how it holds up in your multi-agent runs!
test(browser): prove wcId threads through to resolveTarget in history…
feat(browser): agent-browser engine in the pane
fix(browser): drive a browser surface named by --surface instead of s…