feat(mcp): pilot/co-pilot control handoff for coordinated tasks#99
Closed
brooksc wants to merge 7 commits intojohannesjo:mainfrom
Closed
feat(mcp): pilot/co-pilot control handoff for coordinated tasks#99brooksc wants to merge 7 commits intojohannesjo:mainfrom
brooksc wants to merge 7 commits intojohannesjo:mainfrom
Conversation
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Enable a Claude Code agent to programmatically create and orchestrate other tasks in Parallel Code. Adds an MCP server with 9 tools (create_task, send_prompt, wait_for_idle, get_task_diff, merge_task, etc.), a main-process orchestrator, REST API endpoints, and UI support including coordinator mode toggle, sub-task status strip, and "via Coordinator" sidebar labels. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Cherry-picked from cledoux95/task/coordinating-agent (commit 6650b05). Fixed console.log → console.warn to satisfy eslint no-console rule. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Address review issues from PR johannesjo#31: - Try ports 7777-7800 when starting MCP remote server instead of hardcoding 7777, preventing silent failure when port is in use - Validate REST body fields (name, prompt, timeoutMs, squash, message, cleanup) in orchestrator API routes, returning 400 on bad input Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Adds explicit control handoff between the orchestrating agent and the human user, modelled on a pilot/co-pilot system where control is always unambiguously held by one party. Each sub-task created by a coordinator has a new runtime field `controlledBy: 'orchestrator' | 'human'`. The task panel shows a persistent banner so the user always knows who has the stick: - Orchestrator driving: subtle bar + "Take Control" button - Human in control: amber warning banner "You have control — orchestrator is paused" + "Return to Orchestrator" button When the human holds control, the orchestrator's MCP tools are blocked: - `send_prompt` throws immediately so the coordinator agent knows it cannot proceed and must wait or work on other tasks - `wait_for_idle` resolves immediately so the coordinator is not left hanging; the status signals human control Control returns to the orchestrator only via explicit user action — never automatically. Returning control also fires any queued `waitForIdle` resolvers so the coordinator can resume. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The mcpConfigPath was stored on the task but never forwarded as a CLI argument, so the coordinator agent had no MCP tools available and fell back to bash-based orchestration. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
brooksc
force-pushed
the
feature/orchestrator-control-v2
branch
from
a1949f8 to
0cb8d99
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Builds on the coordinating agent concept from PR #31 to add explicit human/orchestrator control handoff — a pilot/co-pilot model where control is always unambiguously held by one party.
The problem
Without this feature, a coordinating agent can send prompts to sub-tasks at any time. If the user wants to intervene in a sub-task — correct a mistake, redirect the agent, or just inspect what's happening — there's no mechanism to stop the orchestrator from sending competing instructions.
How it works
Each sub-task created by a coordinator has a runtime field
controlledBy: 'orchestrator' | 'human'. The task panel shows a persistent banner so the user always knows who has the stick:When the human holds control, the orchestrator's MCP tools are blocked for that specific task:
send_promptthrows immediately so the coordinator agent knows it cannot proceed and must wait or work on other taskswait_for_idleresolves immediately (non-blocking) so the coordinator isn't left hangingControl returns to the orchestrator only via explicit user action — never automatically. Returning control fires any queued
waitForIdleresolvers so the coordinator resumes cleanly.Changes (control handoff only)
src/store/types.ts—controlledBy?: 'orchestrator' | 'human'onTask(runtime, not persisted)electron/ipc/channels.ts—MCP_ControlChangedchannelsrc/store/tasks.ts+src/store/store.ts—setTaskControl(taskId, who)actionelectron/mcp/orchestrator.ts— enforce control insendPromptandwaitForIdleelectron/ipc/register.ts— handleMCP_ControlChangedIPCsrc/components/TaskPanel.tsx— control banner UITest plan
send_promptMCP call returns an error🤖 Generated with Claude Code