failOnStartupError

[youngreat]

DSH-issue-draft.md

[PerryLink]

Both defects in your issue draft hold up against current master (0.1.6-alpha.1), with a couple of line-number corrections and one thing worth adding. I traced the sources rather than the built lib/; everything below is master as of this writing.

D2 is the solid one. The mount hardcodes the fatal flag — packages/experimental/browser-use-runtime/src/mcp.ts:152-153:

failOnStartupError: true,
reconnect: { enabled: false },

while the client's own default is non-fatal — packages/mcp/mcp-client/src/index.ts:128 and :138 both read failOnStartupError: z.boolean().default(false). The wrapper that turns a contained startup failure into a rejection sits a few lines below where you cited it, at packages/mcp/mcp-client/src/index.ts:200-202:

if (outcome.error !== undefined && config.failOnStartupError) {
  throw new Error(`mcp-client(${config.serverName}): initial connection or tool synchronization failed`, { cause: outcome.error })

And the reason this kills subagent/workflow creation instead of degrading: agent/created listeners run serially and "a throw or rejection fails creation" — packages/core/agent/src/runtime-types.ts:250-253. mountSessionMcp registers there with { prepend: true } and awaits the mount (packages/experimental/browser-use-runtime/src/mcp.ts:177-190), and the provider listener is unscoped, so it fires for every agent, subagents included. One addition for your draft: the pattern is broader than Browser Use — packages/acp/acp/src/mcp.ts:56 and :68 pass failOnStartupError: true for ACP stdio/HTTP servers, and packages/experimental/computer-use-cua-driver-mcp/src/index.ts:60 does the same for the Cua Driver provider.

D1: mechanics verified, timing not. connectWorkspace is packages/client/ui-workspace/src/client/navigation.ts:115-137; the reuse predicate at :128-130 is what you described but additionally requires summary.blank and !archived.includes(summary.id) (:126-131). It creates with this.sessions.create({ workspaceId }) and no cwd (:133), and the client summary synthesized after create carries no cwd either — packages/api/session-controller/src/client/sessions/manager.ts:566-569 only sets cwd when opts.cwd was passed; the attach-failure path (:575-582) also records an ungrouped blank without cwd. The host does derive cwd from the workspace — packages/api/session-controller/src/commands.ts:101 const cwd = workspace?.path ?? request.cwd ?? this.defaultCwd — then attaches at :115 and surfaces 'session/workspace-attach-failed' (:117-121), which the client maps back to a sessionId (manager.ts:1004-1006). watchNavigation resets to 'waiting' on failure (navigation.ts:233-237) and re-runs on every list snapshot change with no retry cap. So a summary whose cwd hasn't been filled by a host refresh fails the reuse test and each retry can mint another blank — that structurally matches your "leak + new chat" story. The exact interleaving of attach vs. list refresh is not verified from source alone; include a repro log if you file it.

Workaround for D2. Edit the installed copy: profiles resolve plugins through $DSH_HOME/profiles/node_modules (packages/boot/app-boot/src/profile.ts:5,19-20), so on your machine that's ~/.dsh/profiles/node_modules/@deepseek-ai/dsh-experimental-browser-use-runtime/ — the compiled mount lives in that package's lib/ output (its ./mcp export maps to lib/types/mcp.js per packages/experimental/browser-use-runtime/package.json:23-26); search for failOnStartupError and flip it to false. Risks: it's a compiled artifact, dsh plugin install or any update re-lays the package and silently reverts the edit, and I haven't run this edit myself (not verified) — disabling the two Browser Use rows is the safer stopgap.

Your draft is ready to file as an issue; the repo's issue template asks for exactly the version/repro you've collected. Happy to double-check your D1 repro log against the attach flow if you post it.

[youngreat]

DSH-issue-draft.md
D1-repro-log.md
check_projcache_cwd.py