8000 Concurrent agents share a single browser window, causing interference · Issue #62 · amirlehmam/wmux · GitHub
[go: up one dir, main page]

Skip to content

Concurrent agents share a single browser window, causing interference #62

Closed

Description

@AxelM-MSK

Problem

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.

Activity

  1. added a commit that references this issue on Jun 26, 2026
  2. amirlehmam commented on Jun 26, 2026

    @amirlehmam
    Owner

    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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      0