No session isolation: concurrent clients share one global browser/tab, causing silent navigation collisions

[johns10]

Summary

The vibium daemon (and, apparently, the MCP server tools too — they seem to share the same underlying browser) is a single global browser instance per machine, with no session/profile isolation between callers. Multiple concurrent clients (multiple AI agents in our case, each with their own MCP connection) all drive the same browser tab/page state.

This causes silent, hard-to-detect collisions: one caller's navigate/click can land on whatever page a different caller just navigated to, with no error — the call just succeeds against the wrong page. browser_get_url right before an action doesn't fully protect against it either, since another caller can navigate between the check and the action.

Repro

With three separate agents each holding their own MCP connection to vibium, running roughly:

agent A: browser_navigate("https://example.com/a")
agent B: browser_navigate("https://example.com/b")   # races A
agent A: browser_click("[data-test=foo]")             # may click on B's page instead of A's

We observed this repeatedly over about 20 minutes of concurrent use — an agent's browser_click/browser_screenshot/browser_get_attribute would silently operate against a completely different URL than the one it had just confirmed with browser_get_url a moment earlier, because another agent's browser_navigate landed in between. browser_new_page + browser_switch_page didn't reliably fix it either — later actions from a different caller still appeared to land on whatever page was globally "current" rather than staying pinned to the page the switching caller had selected.

Ask

Given vibium's stated purpose is browser automation for AI agents, and a very natural pattern is multiple agents working concurrently (subagents, multi-agent orchestration, several people/processes automating the same host), this seems like a significant gap for that use case specifically. Some options that would help:

• Per-connection/per-session browser contexts (e.g., a fresh BrowserContext/incognito-style profile per MCP client connection or per CLI invocation group), so concurrent callers get isolated tabs by default.
• At minimum, make browser_new_page + a page handle genuinely sticky per caller — i.e., once a client creates/switches to a page, all of that client's subsequent calls target that page specifically, unaffected by other clients' navigation, rather than everyone sharing one ambient "current page."
• Failing either of those, some way to detect the collision (e.g., a page/tab generation id returned by browser_navigate that later calls could optionally assert against) so a caller can at least fail loudly instead of silently reading/acting on the wrong page.

Environment

• macOS (Darwin), Apple Silicon
• vibium daemon mode (vibium daemon start --headless)
• Multiple concurrent Claude Code agent processes, each with their own mcp__vibium__* tool connection