fix(ui): close the outgoing ConPTY pane on merge-helper handoff
Each handoff tile is a live claude process with the full mcp__claudedo__* surface; leaving the outgoing phase's pane open leaked one process per phase. Close it via CloseConPtySession before opening the next phase's tile, restoring the one-pane-per-TaskId invariant so OpenConPtySessionAsync's dedupe and OnPaneSubmitForReview can go back to FirstOrDefault.
This commit is contained in:
@@ -1,7 +1,7 @@
|
||||
# ConPTY interactive sessions & launch specs
|
||||
|
||||
> **Explore-note — verify before trusting.** Distilled map of a subsystem, not authoritative.
|
||||
> Last verified against commit `8dbdfb3` (2026-08-06).
|
||||
> Last verified against commit `79b3580` (2026-08-11).
|
||||
> Drift check: `git log --oneline bdee731..HEAD -- src/ClaudeDo.Worker/Planning src/ClaudeDo.Worker/Hub src/ClaudeDo.Worker/Runner/ClaudeArgsBuilder.cs src/ClaudeDo.Ui/ViewModels/MissionControlViewModel.cs src/ClaudeDo.Ui/Views/InteractiveTerminalView.axaml`
|
||||
> Stable structure only (no line numbers). See docs/explore-notes/README.md.
|
||||
|
||||
@@ -115,6 +115,15 @@ share the same prompt/model as their non-final counterpart and differ only in on
|
||||
rendered into the handoff kickoff file (`PromptKind.MergeHelperHandoff`) marking the final round
|
||||
and forbidding further reruns.
|
||||
|
||||
Each handoff hands the SAME handler task id to a NEW tile, and `MissionControlViewModel.
|
||||
OpenMergeHelperHandoffConPtySessionAsync` closes the outgoing phase's pane (`CloseConPtySession`,
|
||||
which disposes its `PtyTerminalSession` and kills the underlying `claude` process) before opening
|
||||
the next one — every tile is a live process with the full `mcp__claudedo__*` surface, and the
|
||||
outgoing session is only ever told to end its turn, never to exit. This keeps the one-pane-per-
|
||||
`TaskId` invariant that `ConPtySessions` relies on elsewhere (`OpenConPtySessionAsync`'s dedupe,
|
||||
`OnPaneSubmitForReview`) — both use a plain `FirstOrDefault(s => s.TaskId == taskId)`, not a
|
||||
"newest wins" lookup.
|
||||
|
||||
`MCP_TOOL_TIMEOUT` is 200 s here — `TaskWaitMcpTools` clamps its own timeout to 170 s to stay
|
||||
comfortably under it (see [external-mcp.md](external-mcp.md)).
|
||||
|
||||
|
||||
Reference in New Issue
Block a user