Browser Use: mounting it makes session creation fail with a misleading 'initial connection or tool synchronization failed' — is this the #3984/#4025 serverName scope issue?

[lonelytxgmail]

Browser Use: multi-session serverName collision rejects session creation with a misleading error

Component: @deepseek-ai/dsh-experimental-browser-use-playwright-mcp (+ dsh-experimental-browser-use-runtime, dsh-browser-use)
Version: 0.1.6-alpha.1
DSH: 0.1.6-alpha.1
Platform: macOS 26.6.2 (Darwin arm64), Node v24.18.0
Severity: blocks session creation entirely once triggered

---

Summary

After mounting Browser Use (Playwright MCP backend) and restarting dsh web, creating or resuming any session fails across all workspaces:

failed to create session "session-<id>": Error:
mcp-client(playwright-mcp): initial connection or tool synchronization failed

The error text points at connection, but the actual failure is a serverName uniqueness collision in dsh-mcp-client's process-wide reservation table. Because Browser Use mounts one MCP client per live Session (all under the fixed name playwright-mcp) with failOnStartupError: true, any overlap between two Sessions' registration windows tears down session creation.

Once Browser Use is disabled, session creation recovers immediately.

---

Environment / config that triggers it

- insert:
    - id: browser-use
      name: '@deepseek-ai/dsh-browser-use'
    - id: browser-use-playwright-mcp
      name: '@deepseek-ai/dsh-experimental-browser-use-playwright-mcp'
      config:
        mode: launch
        headless: true
        executablePath: /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

Profile uses patchReload: live. Another, unrelated MCP server (serverName: dbx) is mounted in the same profile and never fails.

---

Observed symptoms

• Sessions stop being created. Their persisted logs stop after the permission records — exactly 3 lines, ~320 bytes:

{"type":"session","version":3,"id":"session-...","cwd":"...","agentPreset":"standard"}
{"type":"permission/preset","seq":0,"data":{"preset":"workspace-write"}}
{"type":"sandbox/mode","seq":1,"data":{"mode":"workspace-write"}}
{"type":"approval/policy","seq":2,"data":{"policy":"ask"}}

• Fails across every workspace (not workspace-specific) — 20+ such stub sessions accumulated in ~90 seconds across 6 different workspaces.
• Intermittent: rapid successive "new session" clicks fail; retrying after a pause succeeds. One workspace produced FAIL at 16:20:11 and OK at 16:20:32.

---

Root-cause chain (traced in source)

1. dsh-mcp-client reserves serverName process-wide, with a ctx.root fallback

packages/mcp/mcp-client/src/index.ts (apply):

ctx.effect(() => {
  const owner = scopeOf(ctx) ?? ctx.root          // ← falls back to process root
  let names = activeServerNames.get(owner)
  if (!names) { names = new Set(); activeServerNames.set(owner, names) }
  if (names.has(config.serverName)) {
    throw new Error(`mcp-client: serverName "${config.serverName}" is already in use by another mcp-client instance — pick a unique serverName in cordis.yml`)
  }
  names.add(config.serverName)
  return () => void names.delete(config.serverName)
}, 'mcp-client.serverName')

2. Browser Use mounts one MCP client per live Session, all with the same fixed name

packages/experimental/browser-use-runtime/src/mcp.ts (mountSessionMcp), inside SessionResources.open(agent, signal):

await scope.ctx.plugin(McpClient, McpClient.Config({
  transport: 'stdio',
  serverName: options.name,        // fixed per provider — 'playwright-mcp' for every Session
  command: options.command,
  args: options.args,
  failOnStartupError: true,        // ← turns a contained conflict into a fatal one
  reconnect: { enabled: false },   // ← no retry
}))

and the provider passes the constant name (browser-use-playwright-mcp/src/index.ts):

mountSessionMcp(ctx, {
  name: 'playwright-mcp',
  exclusive: config.mode === 'attach',
  ...
})

3. failOnStartupError: true makes the collision fatal, then wraps it in a misleading message

dsh-mcp-client:

const opts = { registrationFailure: 'contain', serverName: config.serverName, ... }
const startupOpts = config.failOnStartupError
  ? { ...opts, registrationFailure: 'throw' }    // ← Browser Use path
  : opts                                          // ← ordinary MCP servers stay contained
...
const outcome = await connection.ready
if (outcome.error !== undefined && config.failOnStartupError) {
  throw new Error(`mcp-client(${config.serverName}): initial connection or tool synchronization failed`, { cause: outcome.error })
}

4. Browser Use mounts during the serial, blocking agent/created event

mountSessionMcp:

ctx.on('agent/created', async ({ agent, signal }) => {
  ...
  await resources.get(agent, signal)   // awaits the MCP client's connection + discovery
  clients.set(agent, state)
}, { prepend: true })

Because agent/created is serial and awaited, a throw here prevents session creation from ever completing — which is exactly the 3-line stub logs above.

Why only Browser Use breaks

serverName reservation is process-global while the tool registry it feeds is per-agent scoped. Two live Sessions legitimately wanting the same MCP server collide on the name check even when teardown is perfect and instantaneous. Ordinary MCP servers (dbx here) survive because they use the default failOnStartupError: false, which contains the failure instead of throwing.

This matches the analysis already on file in #3984 / #4025 (scope mismatch: activeServerNames keyed on ctx.root vs per-agent tool visibility), except the Browser Use path escalates the collision into a hard session-creation failure.

---

Evidence that the MCP server itself is healthy

The failure is not in the Playwright MCP process. All of the following succeeded while Browser Use was mounted and failing:

• Same command DSH spawns, using DSH's own scrubbedParentEnv() + StdioClientTransport:
  OK cwd=/Users/lee/LeeProject/space tools=24 148ms
• 10 concurrent instances across 4 different cwd values (including non-ASCII paths):
  all OK, 24 tools each, ~380 ms
• 8 concurrent instances in the same second: all OK
• Manual runs under the exact failing workspace cwd: all OK
• initialize returns protocolVersion 2025-06-18; tool list = 24 tools

Ruled out as causes: executablePath value, working directory, non-ASCII paths, memory pressure (71 % free), git presence, Chrome singleton lock, concurrent MCP spawn count.

---

Suggested direction

Any one of these would prevent a recoverable condition from killing session creation:

1. Scope serverName uniqueness to the registering agent scope rather than ctx.root, matching where the tools actually live — or, if per-process uniqueness is intentional (double-spawn protection), make the error message say so and document the concurrent-Session restriction explicitly.
2. Do not let a per-Session provider mount be fatal to agent/created — a failed browser mount should leave that Session without browser tools (the documented blocked behavior in SessionResources) instead of rejecting creation.
3. Include cause in the surfaced error. The wrapper message names "connection or tool synchronization", which sends diagnosis down the wrong path; the actual cause was a registration collision.

Note: simply deleting the reservation before checking (as floated in #3984) would make two instances share one serverName silently; #4025 already argues that is worse than the deterministic error.

---

Workaround

Disabling the two Browser Use rows restores session creation immediately. Because --isolated is hard-coded in the launch branch, launch cannot persist a profile, so there is no config-level way to avoid the per-Session mount short of not using the provider.

Below is the machine-translated Chinese version. 以下为中文版。

---

Browser Use：多会话 serverName 冲突导致会话创建被拒，且报错信息误导

组件： @deepseek-ai/dsh-experimental-browser-use-playwright-mcp（含 dsh-experimental-browser-use-runtime、dsh-browser-use）
版本： 0.1.6-alpha.1
DSH： 0.1.6-alpha.1
平台： macOS 26.6.2（Darwin arm64），Node v24.18.0
严重程度： 一旦触发，会话创建被完全阻断

概述

挂载 Browser Use（Playwright MCP 后端）并重启 dsh web 后，所有工作区的新建与恢复会话全部失败：

failed to create session "session-<id>": Error:
mcp-client(playwright-mcp): initial connection or tool synchronization failed

报错文字指向「连接」，但真实原因是 dsh-mcp-client 进程级 serverName 保留表中的唯一性冲突。由于 Browser Use 为每个活动会话挂载一个 MCP 客户端（名字固定为 playwright-mcp），并设置 failOnStartupError: true，任意两个会话的注册窗口重叠，就会让会话创建失败。

停用 Browser Use 后，会话创建立即恢复。

触发配置

- insert:
    - id: browser-use
      name: '@deepseek-ai/dsh-browser-use'
    - id: browser-use-playwright-mcp
      name: '@deepseek-ai/dsh-experimental-browser-use-playwright-mcp'
      config:
        mode: launch
        headless: true
        executablePath: /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

Profile 使用 patchReload: live。同一 profile 内另一个无关的 MCP 服务器（serverName: dbx）从不失败。

观察到的现象

• 会话不再被创建，其持久化日志停在权限记录之后——正好 3 行、约 320 字节（见上方 JSON）。
• 跨所有工作区失败（与工作区无关）：约 90 秒内在 6 个不同工作区累积了 20 多个这样的空壳会话。
• 间歇性：快速连续点击「新会话」会失败，停顿后重试则成功。同一工作区在 16:20:11 失败、16:20:32 成功。

根因链条（源码追溯）

1. dsh-mcp-client 以进程级方式保留 serverName，并回退到 ctx.root：const owner = scopeOf(ctx) ?? ctx.root，随后若名字已存在即抛错。
2. Browser Use 为每个活动会话挂载一个 MCP 客户端，名字固定：serverName: options.name（提供方传常量 'playwright-mcp'），同时 failOnStartupError: true、reconnect: { enabled: false }。
3. failOnStartupError: true 把冲突升级为致命：mcp-client 默认 registrationFailure: 'contain'，Browser Use 路径改为 'throw'；最终包装成 mcp-client(...): initial connection or tool synchronization failed。
4. Browser Use 在串行阻塞的 agent/created 中挂载（{ prepend: true } 且 await resources.get(...)），因此抛错会让会话创建永远无法完成——这正是那 3 行空壳日志的成因。

为什么只有 Browser Use 会坏

serverName 保留是进程全局的，而它服务的工具注册表是按 agent 作用域的。两个活动会话合法地想挂载同一个 MCP 服务器时，即使 teardown 完美且即时，也会在名字检查上冲突。普通 MCP 服务器（此处的 dbx）因为使用默认的 failOnStartupError: false 而把失败包容掉，所以不受影响。

这与 #3984 / #4025 中已有的分析一致（activeServerNames 以 ctx.root 为 key 与 per-agent 工具可见性之间的作用域不匹配），差别在于 Browser Use 路径把这个冲突升级成了硬性的会话创建失败。

MCP 服务器本身健康的证据

故障不在 Playwright MCP 进程内。在 Browser Use 已挂载且正在失败期间，以下全部成功：

• 使用 DSH 自身的 scrubbedParentEnv() + StdioClientTransport 启动同一命令：OK ... tools=24 148ms
• 跨 4 个不同 cwd（含非 ASCII 路径）并发 10 个实例：全部 OK，各 24 工具，约 380 ms
• 同一秒内并发 8 个实例：全部 OK
• 在失败工作区的确切 cwd 下手动运行：全部 OK
• initialize 返回 protocolVersion 2025-06-18；工具数 24

已排除：executablePath 取值、工作目录、非 ASCII 路径、内存压力（71% 空闲）、git 存在性、Chrome 单例锁、并发 MCP 启动数量。

建议方向

1. 把 serverName 唯一性收窄到注册的 agent 作用域，与工具实际所在的作用域一致；若进程级唯一性是刻意设计（防重复拉起），请在报错与文档中明确说明该并发限制。
2. 不要让 per-session 的提供方挂载对 agent/created 致命——浏览器挂载失败应让该会话没有浏览器工具（即 SessionResources 中已有的 blocked 行为），而不是拒绝会话创建。
3. 在抛出的错误中带上 cause。当前包装信息说「连接或工具同步」，把排查引向错误方向；实际原因是注册冲突。

注：像 #3984 中设想的「先删再查」会让两个实例静默共用同一个 serverName；#4025 已论证这比确定性报错更糟。

规避方式

停用这两行 Browser Use 配置即可立即恢复会话创建。由于 launch 分支中 --isolated 是硬编码的，launch 无法持久化 profile，因此在配置层面除了不使用该提供方之外，没有其他办法避免 per-session 挂载。

[PerryLink]

Short version: your chain checks out on master up to the last link, with two corrections — the reservation is no longer process-global for this mount, and the thrown error now carries the real cause even though the message text still hides it.

Verified against master (0.1.6-alpha.1), current paths:

• Reservation: packages/mcp/mcp-client/src/index.ts:162-176 is verbatim what you quoted, including const owner = scopeOf(ctx) ?? ctx.root (:163) and the throw at :170-172.
• Mount: packages/experimental/browser-use-runtime/src/mcp.ts:144-154 — failOnStartupError: true (:152), reconnect: { enabled: false } (:153); registered on agent/created with { prepend: true } and awaited (:177-190). agent/created is serial and a throw fails creation — packages/core/agent/src/runtime-types.ts:250-253.
• contain vs throw: packages/mcp/mcp-client/src/connection.ts:130-140 — opts default to registrationFailure: 'contain' (:131), the startup path switches to 'throw' (:138-140). You cited 135-138; on master it's 130-140.
• Provider: packages/experimental/browser-use-playwright-mcp/src/index.ts:42-49 — name: 'playwright-mcp' (:43), exclusive only in attach mode (:44), and launch hardcodes --isolated (:38), so every session spawns its own Chromium and there's no config-level way to avoid the per-session mount.

Where I'd push back on your own analysis:

1. The reservation is not process-global for this mount on master. The doc comment at index.ts:43-46 explicitly says agent-scoped servers may reuse a name in another agent; the mount runs under a per-agent scope (mcp.ts:130 const scope = createScope(ctx, agent), then :144 scope.ctx.plugin(McpClient, ...)), and Cordis context inheritance carries the scope tag (vendor/cordis/src/context.ts:99-107). A test pins the behavior: packages/mcp/mcp-client/tests/apply.spec.ts:244 "allows one serverName in each independent registration scope". So a pure two-session overlap should not hit the reservation throw on current master — which suggests your observed failures had a different first-attempt error.
2. That error is now recoverable. The wrapper throw at index.ts:200-202 includes { cause: outcome.error }, so the real first-attempt failure is attached to the Error object on master even though the message string is still the misleading "initial connection or tool synchronization failed" — and the surfaced create-session line you captured shows only the message. Re-running while logging the full error object (or err.cause) will settle which leg of your chain actually fired.

Your workaround (disable the two Browser Use rows) is sound and is effectively the only option while the per-session mount is hardcoded. The cross-links are apt: #3984 is the lifecycle-leak report, #4025 the scope-mismatch analysis, and this is the same failOnStartupError family as #6837 (which also covers the subagent/workflow angle).

I haven't reproduced the intermittent failure locally (not verified) — if you can capture the cause from one failing run on macOS, please post it; it would confirm whether the collision, a slow first Chromium start under load, or something else is the real trigger.