[Juliusolsson05]

Fixes #952.

The incident

On 2026-09-12 one orchestration_create_agent call produced two children 0.9 s apart — same title, cwd, role and prompt, both bootstrapped, both working in the same worktree and writing the same report path. Only one was returned, so the parent could neither see nor close the other and it ran unobserved.

What was ruled out, and what was not

• request / dispatchRendererRequest send once. There is no retry path.
• The only timeout is 30 s. The observed gap was 0.9 s.
• The renderer request is addressed to one window, never broadcast — a decision made in f7b4408a (Refs feat(window): support multiple application windows for multi-monitor workspaces #688), because answering an MCP mutation from the wrong window's workspace model is worse than not answering.
• Not a double renderer handling either: a second resolveOrchestrationRequest for an already-resolved requestId is dropped, so the extra child would carry no prompt-delivery record and no delivered bootstrap prompt — and both children were bootstrapped.

That leaves a second complete tool invocation, which points above this process. Nobody observed it, so this PR does not claim a root cause. It makes the operation idempotent, because the damage is real whatever the cause.

What it does

orchestration_create_agent runs through bridge.createAgentCallOnce(key, …). An identical call arriving while one is still running awaits it and returns its result.

The unit is the whole tool call, not createAgent. One invocation is create → deliver the bootstrap prompt → mark delivered, and the delivery is the slow, failure-prone part. It lives on the bridge because BuiltInMcpHttpHost builds a fresh server with a stateless transport per POST — a map owned by the server would never see the duplicate — while the key is built by the tool handler, which owns the argument schema.

The key is every argument, prompt included. Two creates that differ by prompt are two different jobs. It is typed Record<keyof OrchestrationCreateAgentArgs, unknown> so the next field added to the tool is a compile error rather than a silent over-collapse, builtInMcpDomains is sorted, and [] normalizes with absent.

In flight only. A window over completed calls would swallow a deliberate "run that exact task again".

What the first version got wrong

The review on this PR caught a regression worse than the bug. Keyed on the child's shape with the prompt excluded, a concurrent fan-out of N workers differing only by prompt collapsed into one child — N-1 tasks silently never run, the losing callers handed prompt_delivery_failed with disposition: 'retry-same-session', an instruction to re-send the prompt into the child already running it, plus a false incident in the always-on journal. MAX_ACTIVE_RENDERER_REQUESTS = 1 makes such a burst overlap by construction, so a fan-out was the most exposed shape.

Five of the eight key fields were also unconstrained by the tests — dropping cwd from the key would have handed a caller a child working in the wrong repository, with the suite green.

Tests

orchestrationDuplicateCreate.system.test.ts drives the real MCP server, the real tool handler and the real bridge over an in-memory transport. Only the two true edges are faked: sendToWindow (no renderer here) and deliverPromptToAgent — and that fake reproduces SessionManager's real in-flight reservation, because a duplicate colliding with it is one of the failures being fixed.

mutation	result
remove the dedupe (the bug)	4 failed
key drops prompt (the fan-out)	2 failed
key drops cwd / providerRuntime / runId	1 failed each
key drops role / title / kind	1 failed each
key drops builtInMcpDomains	1 failed
domains not sorted	1 failed
parentSessionId out of the key	1 failed
never clear the in-flight entry	2 failed
dedupe the create instead of the call	2 failed
restored	16 passed

npx tsc -b clean; src/main/orchestration/ + src/mcp/ 48 passed.

🤖 Generated with Claude Code

[Juliusolsson05]

Review round addressed. Findings 1, 2 and 4 turned out to be one fix, and finding 1 was right that the first version was worse than the bug.

The fan-out collapse was the real defect here. Keying on the child's shape with the prompt excluded meant N concurrent workers differing only by prompt became one child, and N-1 tasks were silently never run — which is exactly how I dispatch reviewers on this repo. Your rationale rebuttal was also correct: args.prompt is in hand three lines above the createAgent call and simply was not passed down. The prompt is in the key now.

2 and 4 fall out of moving the unit to the whole tool call. A duplicate now awaits the first invocation and receives its result, so there is no second deliverPromptToAgent, no prompt_delivery_failed carrying retry-same-session for a child that is already running the prompt, no false journal incident, and no window that ends before the slowest segment. It went on the bridge for the reason you identified — BuiltInMcpHttpHost builds a fresh server per POST, so a server-owned map would never see the duplicate.

3 — your mutation table was the most useful thing in the review. All five surviving fields are pinned now, through the real server and the real handler rather than the bridge in isolation:

mutation	before	after
key drops cwd	14 passed	1 failed
key drops providerRuntime	14 passed	1 failed
key drops runId	14 passed	1 failed
key drops role	14 passed	1 failed
key drops builtInMcpDomains	14 passed	1 failed

Plus prompt (2 failed), parentSessionId, unsorted domains, and "dedupe the create instead of the call" (2 failed).

5 — the #992 attribution was wrong and I have replaced it with f7b4408a (Refs #688) and its actual reason. The "arrived from the MCP client" line now states what was ruled out and stops, including the double-renderer-handling argument you verified.

6 — the key is Record<keyof OrchestrationCreateAgentArgs, unknown> over a named schema constant. 7 — domains sorted, [] normalized with absent. 8 — the fake renderer answers every request type, so an undeduped duplicate fails on an assertion instead of hanging for 5 s.

Fixes #952 kept: the window now covers the entire invocation rather than a fraction of it, which is the coverage the body previously implied without showing.