[Bug] v0.1.6-alpha.1: "only one session can stay in browser" bug - by browser-use with attach mode

[frankisze]

[Bug] v0.1.6-alpha.1: browser-use runtime declares dsh-scope as a dependency — the profile loads two copies and every session after the first fails

Summary

Since v0.1.6-alpha.1, any profile that mounts the official browser-use provider (@deepseek-ai/dsh-browser-use + @deepseek-ai/dsh-experimental-browser-use-playwright-mcp) can no longer create a second session. The first session works; every session created while it is open fails, with the UI either doing nothing or discarding a saved session row.

The cause is not browser-use. @deepseek-ai/dsh-experimental-browser-use-runtime@0.1.6-alpha.1 declares @deepseek-ai/dsh-scope as an ordinary dependency, so the package manager materializes a second physical copy of dsh-scope inside the profile's own node_modules. dsh-scope identifies a scope with a plain per-module symbol, so with two copies scopeOf(agent.ctx) returns undefined for a genuinely scoped context. Core APIs that need that resolution then either throw or silently fall back to the global layer, and because the failing calls run inside the agent/created hook, session creation aborts.

The same manifest already lists @deepseek-ai/dsh-tools, dsh-agent, dsh-browser-use and cordis as peerDependencies — exactly the treatment dsh-scope and dsh-mcp-client do not get.

Environment

dsh	@deepseek-ai/dsh@0.1.6-alpha.1 (npm alpha)
dsh-scope	0.1.6-alpha.1, two physical copies loaded per process
browser-use packages	@deepseek-ai/dsh-browser-use, @deepseek-ai/dsh-experimental-browser-use-playwright-mcp, @deepseek-ai/dsh-experimental-browser-use-runtime — all 0.1.6-alpha.1
OS	Windows 11 x64
Node.js	v24.19.0
Profile	CLI-created profile (dsh --profile repro --from-default-profile web)
Reproduced	twice: on a long-lived install and on a clean machine

Steps to reproduce

1. Install @deepseek-ai/dsh@0.1.6-alpha.1 and create an empty profile:

   npm i -g @deepseek-ai/dsh@alpha
   dsh --profile repro --from-default-profile web
   

2. Add the official browser-use plugins (the documented flow — the CLI appends them to dsh.profile.bundles):

   dsh plugin --profile repro add @deepseek-ai/dsh-browser-use @deepseek-ai/dsh-experimental-browser-use-playwright-mcp
   

3. Because mode: launch masks the failure (see below), mount the provider in attach mode instead. %USERPROFILE%\.dsh\profiles\repro\cordis.patch.yml:

   - 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: attach
           endpoint: http://127.0.0.1:9222

4. Start a Chrome with a live CDP endpoint and start the UI:

   & "C:\Program Files\Google\Chrome\Application\chrome.exe" `
       --headless=new --remote-debugging-port=9222 `
       --user-data-dir="$env:USERPROFILE\.dsh\chrome-cdp-repro" about:blank
   curl.exe -s http://127.0.0.1:9222/json/version      # must return JSON
   
   dsh --profile repro web

5. Create session #1, send hi. It works, and browser tools are available.

6. Leave session #1 open. Create session #2, send hi. It fails.

Actual result

DevTools → Console (with Preserve log) shows the rejected RPC:

{
  "type": "server-response",
  "rpcId": "…",
  "result": {
    "ok": false,
    "error": {
      "code": "gateway/internal",
      "message": "failed to create session \"session-…\": Error: tools.restrict() requires a scoped context (agent.ctx): a context-global restriction would mask every agent — deny the tool for the intended agent instead"
    }
  }
}

UI-level symptoms of this one failure:

Clicking "New session" does nothing
Clicking a saved session makes its row vanish until the page is refreshed
Choosing a workspace folder fails to create a session
A ~330-byte orphan session file is written each time	exactly 3 records, then nothing

The same defect produces a second, differently-worded error when the second Agent goes down the tool-registration path instead:

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

with the underlying cause visible only in the server log:

mcp-client(playwright-mcp): tool registration failed, no tools registered:
  Error: tool "mcp__playwright-mcp__browser_close" is already registered
         (for a per-agent variant, register through that agent's `agent.ctx` instead)
    at NamedEntries.duplicateError (…/@deepseek-ai/dsh-tools/lib/index.js:2634:59)
    at ScopedLayers.<anonymous> (…/@deepseek-ai/dsh-scope/lib/index.js:206:12)
    at Proxy.register (…/@deepseek-ai/dsh-tools/lib/index.js:2884:22)

Expected result

Session creation should not depend on whether another session holds the browser. The provider's own contract says so — dsh-experimental-browser-use-runtime/lib/types/mcp.js:39-45:

Await one MCP client during each future Agent's creation. A busy attachment leaves that activation without browser tools; its other turns continue. Calls are serialized per Session.

i.e. the second activation should lose browser tools and keep working, not abort session/create.

Evidence — verified against the npm registry

The published manifests were read directly from the registry.

1. @deepseek-ai/dsh-experimental-browser-use-runtime@0.1.6-alpha.1 — https://registry.npmjs.org/@deepseek-ai/dsh-experimental-browser-use-runtime/0.1.6-alpha.1

"dependencies": {
  "@deepseek-ai/dsh-scope": "^0.1.6-alpha.1",
  "@deepseek-ai/schemastery": "^3.18.2",
  "@deepseek-ai/dsh-mcp-client": "^0.1.6-alpha.1"
},
"peerDependencies": {
  "@deepseek-ai/cordis": "^4.0.2",
  "@deepseek-ai/dsh-agent": "^0.1.6-alpha.1",
  "@deepseek-ai/dsh-tools": "^0.1.6-alpha.1",
  "@deepseek-ai/dsh-browser-use": "^0.1.6-alpha.1",
  "@deepseek-ai/dsh-system-prompt": "^0.1.6-alpha.1"
}

dsh-tools, dsh-agent, dsh-browser-use and cordis are peers — the host provides them, one copy each. dsh-scope and dsh-mcp-client are ordinary dependencies, so the package manager is obliged to materialize its own copies.

2. @deepseek-ai/dsh-experimental-browser-use-playwright-mcp@0.1.6-alpha.1 depends only on @playwright/mcp@0.0.80 and the runtime; it does not pull dsh-scope directly. The duplication originates in the runtime's manifest.

3. Resulting install layout — <profile>\node_modules\@deepseek-ai\:

cosmokit                                    <REAL DIR>   duplicated
dsh-browser-use                             <REAL DIR>   profile-only
dsh-experimental-browser-use-playwright-mcp <REAL DIR>   profile-only
dsh-experimental-browser-use-runtime        <REAL DIR>   profile-only
dsh-mcp-client                              <REAL DIR>   duplicated
dsh-scope                                   <REAL DIR>   duplicated  ←
dsh-util-values                             <REAL DIR>   duplicated
schemastery                                 <REAL DIR>   duplicated

None of these is a link, while the host continues to resolve its own copies from the global install:

$a = "$env:USERPROFILE\.dsh\profiles\repro\node_modules\@deepseek-ai\dsh-scope\lib\index.js"
$b = "$(npm root -g)\@deepseek-ai\dsh\node_modules\@deepseek-ai\dsh-scope\lib\index.js"
(Get-Item $a).FullName -eq (Get-Item $b).FullName
# False   — two distinct physical files, therefore two module instances

Root cause

packages/core/scope/src/index.ts (read from a pristine checkout — git status --porcelain empty, HEAD 141eb6fef8):

:18      const kScope = Symbol('dsh.scope')

:137-140 export function createScope(ctx, key, options) { …
           const scoped: Context = fiber.ctx.extend({ [kScope]: key }) }

:154-155 export function scopeOf(ctx) { return (ctx as …)[kScope] }

createScope writes ctx[kScope]; scopeOf reads ctx[kScope]. Symbol() returns a new unique symbol on every evaluation, so the handshake only works when both sides hold the same object — i.e. when dsh-scope exists once in the process. With two copies, scopeOf(agent.ctx) is undefined.

Two core APIs then ask that question and get the wrong answer:

A — the designed-degradation path throws. In dsh-experimental-browser-use-runtime/lib/types/mcp.js, a second activation against an exclusive resource is admitted as blocked, then masked:

// :53-70
const refreshBlockedMasks = () => {
    …
    try {
        for (const [agent, state] of clients) {
            if (state.status !== 'blocked') continue;                              // :59
            …
            state.mask ??= createScope(ctx, agent);                                // :64  writes kScope[copy B]
            state.mask.ctx.tools.restrict({ deny: inherited.map(t => t.name) });   // :65  reads kScope[copy A]
        }
    }
    finally { refreshingMasks = false; }        // :68  try/finally — no catch
};

dsh-tools/lib/index.js:2894-2895 then throws, and the exception escapes refreshBlockedMasks → the agent/created handler at :129-141 → session creation.

B — tool registration lands in the global layer. dsh-tools.register() is documented as "Register globally or in the calling agent scope" and resolves the layer with the same scopeOf (:2876-2884). Degraded, every Agent's MCP tools are inserted into the global layer, so the second insertion trips NamedEntries.duplicateError (:2634) — the stack quoted under Actual result. Because the provider hardcodes failOnStartupError: true (mcp.js:102), dsh-mcp-client swaps its default registrationFailure: "contain" for "throw" (dsh-mcp-client/lib/index.js:489-493, rethrown at :155-157) and wraps it as initial connection or tool synchronization failed (:832), which is what makes an otherwise contained conflict fatal.

Why mode: launch hides it

The provider makes the browser resource exclusive only in attach mode (dsh-experimental-browser-use-playwright-mcp/lib/index.js:40):

exclusive: config.mode === "attach",

so under mode: launch — the example in the provider README — available() short-circuits to true for every Agent (dsh-experimental-browser-use-runtime/lib/types/index.js:45-49), status is never 'blocked', and line :65 is unreachable. The defect needs attach mode or two concurrent Agents to surface; with a single session nothing looks wrong. Ordinary MCP servers are also unaffected because they keep the default failOnStartupError: false, which contains the same conflict.

Workaround (confirmed working)

Replace the profile-local real copies of modules that are also provided by the host with directory junctions pointing at the host copy, so each module has exactly one physical file per process:

# quit dsh completely first — a running node.exe keeps these directories locked
$p = "$env:USERPROFILE\.dsh\profiles\repro\node_modules\@deepseek-ai"
Move-Item "$p\dsh-scope" "$p\dsh-scope.bak"
New-Item -ItemType Junction -Path "$p\dsh-scope" `
         -Target "$(npm root -g)\@deepseek-ai\dsh\node_modules\@deepseek-ai\dsh-scope"

Applied to all five duplicated modules (dsh-scope, dsh-mcp-client, cosmokit, dsh-util-values, schemastery); the three profile-only browser-use packages are correctly left alone, as the host has no copy to point at. Only dsh-scope is strictly necessary — the other four do not export identity tokens. Session creation recovers immediately.

Two caveats: it must be re-applied after any pnpm install / dsh plugin add, and it should touch only <profile>\node_modules\@deepseek-ai\* — do not wipe $DSH_HOME/profiles/node_modules, since the heal step rebuilds only the install closure and would drop third-party scopes.

Suggested fixes (any of the three)

• (a) Move @deepseek-ai/dsh-scope and @deepseek-ai/dsh-mcp-client from dependencies to peerDependencies in @deepseek-ai/dsh-experimental-browser-use-runtime and re-publish — the identical treatment dsh-tools, dsh-agent and dsh-browser-use already receive in that same manifest. This removes the duplication at its source for every profile.
• (b) Make the scope tag cross-instance in core: packages/core/scope/src/index.ts:18 → const kScope = Symbol.for('dsh.scope'). This is layout-independent and is the level the fix belongs at; it is also this repo's existing idiom (Schemastery uses Symbol.for('schemastery')). Note it covers the Symbol facet only — dsh-scope also keeps carrier state in module-local collections, so (a) and (b) are complementary, not alternatives.
• (c) Contract the blast radius: give refreshBlockedMasks a catch so the documented blocked degradation cannot abort agent/created; do not let a per-Session provider mount turn session/create into a 500; and include cause in the wrapped MCP error, which currently sends diagnosis toward "connection" when the failure is registration.

Related reports

• #3148 — same root cause, same one-line fix, with a branch to cherry-pick (kongminOS/deepseek-harness:fix/dsh-scope-symbol-for).
• #2149 — same class of defect via dsh-scope's module-local WeakMap carrier registry (isScopeCarrier() false for every dispatch).
• #6722 and #6755 — the same browser-use symptom under mode: launch, with the duplicate-registration stack.
• #3984 → #4025 — the design-level note that activeServerNames is keyed process-wide while the tool registry is per-agent, i.e. the ctx.root fallback this report explains the precondition of.
• #6459 — the shared profiles/node_modules fallback tree is rewritten per install anchor; do not delete it wholesale.

Screenshots of the install layout, the two-copies check and the workaround's verification output are attached below.