feat(orchestration): stop confirming closes of an agent's own children

[Juliusolsson05]

Orchestration MCP closes (close_agent, close_run) raised a confirmation dialog on every call. Those agents are disposable — the parent created them for a task, and closing them when it's done is the normal end of their lifecycle. A dialog that fires on routine housekeeping is how "are you sure?" stops meaning anything by the time it guards something that matters.

Result: routine fleet cleanup is now silent. The dialog survives only for the closes that genuinely reach further than the agent being named.

Why it isn't simply preConfirmed: true

That was the first attempt, and both reviewers blocked it. The safety argument was wrong.

The ownership gate (isVisibleToOrchestrationParent) scopes which session may be named, not which sessions die. closeSession kills a set, and the gate never sees that set. Two shapes reach past the target:

• Linked agents. A user can run "Linked Agent…" on an orchestration child — orchestration children are ordinary Dispatch rows, so they're selectable. That linked agent carries no orchestration fields, so the gate cannot see it. closeLinkedChildren would have killed a hand-built session silently, and it wouldn't even appear in closedSessionIds.
• Sole grid leaf. Closing a tab's only pane takes every detached session in that tab. Orchestration children live detached in the root's tab — so a close could take the caller itself, its siblings, and any Dispatch agent the user parked there, while reporting one id.

The decisive evidence: Agent Management already refuses both shapes outright (additionalCloseImpact → close_would_affect_additional_sessions) even though it has a dialog available. Orchestration's only equivalent protection was the dialog.

The fix: scope the silence, don't remove it

A new silentIfSoleTarget option resolves inside closeSession, where paneCloseTargets is in scope — the only code that computes the full set a close destroys, which a caller cannot know from outside.

• Close expands to exactly the named session → silent. This is the routine case and the whole point of the PR.
• Close expands further → dialog, naming the requesting agent.

CloseSessionOptions' doc calls preConfirmed an ASSERTION and "deliberately NOT a convenience for 'this close feels safe'" — it now records why orchestration doesn't qualify and what it uses instead.

Two reporting bugs fixed on the way

• close_run told the parent every agent closed. It pushed to closedSessionIds unconditionally and relied on a decline throwing to reach its catch — but the gate resolves false, it never rejected. close_agent was worse: no branch at all. Both now branch on closeSession's boolean.
• Agent Management reported a declined close as success. Its own comment claimed "declining rejects the tool call"; it didn't. That's the one surface where a decline is still possible, so it's where the lie mattered most.

close_agent also gained the catch close_run already had — a rejected backend kill runs after closeLinkedChildren, so a bare throw could report neither closed nor skipped with children already dead.

Tests

orchestrationClose.test.ts — 14 cases. The contract is "does it tell the truth", since a parent that believes a child closed stops waiting on it:

• every close carries silentIfSoleTarget, never preConfirmed — a regression to the latter would destroy user sessions silently, and dropping it entirely would put dialogs back on routine cleanup
• closed / didn't-close / threw each report correctly; skippedSessionIds omitted rather than empty
• the runId filter, which is now close_run's sole blast-radius control and previously had zero coverage
• non-agent kinds excluded, empty-run case, ownership gate refusals

Verification

• npx tsc -b → exit 0
• NODE_ENV=test npx vitest run → 256 files, 1775 tests, all passing
• npm run check:keybindings → OK
• npm run test:contract → satisfied

Earlier runs showed 1–4 failures around store.test.ts; all were 5s-timeout flakes under concurrent load from the review agents. Both reviewers independently confirmed they're pre-existing and outside this PR's import graph, and a clean run with no contention is fully green.

Not verified: the live MCP flow — the app was not launched.

🤖 Generated with Claude Code