Repository navigation
autopilot_fleet plan approval may not activate fleet mode immediately (race condition) #1901
Description
Describe the bug
When selecting "Accept plan and build on autopilot + /fleet" (autopilot_fleet) from the plan approval menu, fleet mode may not activate immediately. In my case, the agent continued working interactively for ~50 minutes, and fleet mode only activated after the interactive loop fully completed.
It appears the exit_plan_mode tool result tells the LLM "parallel subagent execution has started," but the /fleet message gets queued behind the already-running agentic loop and isn't processed until the loop finishes. Since this appears to be a race condition, it may not reproduce every time.
Affected version
0.0.422
Steps to reproduce the behavior
- Start a session with
/planon a task with parallelizable work - Agent creates a plan and calls
exit_plan_modewithautopilot_fleetas the recommended action - Select "Accept plan and build on autopilot + /fleet"
- Confirm autopilot permissions when prompted
- Observe: In my case, the agent immediately started working interactively (reading files, making edits) instead of entering fleet mode and dispatching sub-agents
- Fleet mode only activated ~50 minutes later, after the interactive agentic loop fully completed
Expected behavior
After selecting autopilot_fleet, the session should immediately enter fleet mode and the agent should begin dispatching parallel sub-agents via the task tool. The fleet mode prompt ("You are now in fleet mode. Dispatch sub-agents...") should be injected before the next model turn, not queued behind it.
Additional context
- OS: Windows 11 (x64)
- Terminal: Windows Terminal
- Shell: PowerShell 7
- Model: claude-opus-4.6-1m
- Session ID:
24873767-9ee6-4297-8678-5866320fb3ab
Evidence from ~/.copilot/logs/:
| Timestamp (UTC) | Event |
|---|---|
| 14:47:57 | Model calls exit_plan_mode with autopilot_fleet |
| 14:55:55 | User approves plan -> tool returns "parallel subagent execution has started" |
| 14:56:07 | Model responds by reading files interactively (not fleet mode) |
| 15:09-15:41 | Sub-agents dispatched manually hit cascading API timeouts |
| 15:46:05 | Fleet mode finally activates (~50 min after approval) |
The events.jsonl shows the exit_plan_mode tool with selected_action: "autopilot_fleet" immediately followed by regular view tool calls, confirming the agent was not in fleet mode.
The fleet mode statement first appears in the log at 15:46:05 -- a new configured settings group starts at that point, indicating a fresh non-interactive session was created for fleet mode only after the interactive loop drained. This suggests a race condition where the fleet start message is queued behind the already-processing agentic loop.
Activity
MrRishabhJain commentedon Jun 19, 2026
Confirming this still reproduces on GitHub Copilot CLI 1.0.64 (the original report was 0.0.422), so the behavior has persisted across many releases.
Environment
What I saw
/planmode; at plan approval the agent recommended the autopilot +/fleetaction./fleetcommand stayed parked in the Queued region while the main agent went ahead and implemented the plan itself — reading files and applying edits serially, with no parallel sub-agents dispatched. Net effect matches this issue: the fleet message is queued behind the already-running agentic loop, and the plan gets implemented without fleet.One nuance vs. the original report: in my run I could not confirm that fleet ever activated — the plan was fully carried out by the main agent, so from the user's perspective the
/fleetselection had no visible effect. I can't say whether the queued/fleetwould have eventually fired after the loop drained (the ~50-min-late activation described above) or stayed stuck indefinitely.Either way it looks like the same root cause: the fleet-start message is enqueued behind the in-flight agentic loop instead of being injected before the next model turn.
dimanardiyansah123-stack commentedon Jun 19, 2026
#1901
patniko commentedon Oct 26, 2026
Thanks for the detailed report and logs. This is fixed in Copilot CLI v1.0.93: when you accept a plan with "autopilot + /fleet", the fleet instructions are now delivered as part of the plan-approval result itself instead of being queued as a separate
/fleetmessage behind the running agent loop, so the agent starts dispatching parallel subagents right away. If you still see the plan implemented serially without fleet mode on the latest version, please let us know and we'll reopen.Triaged as part of a Copilot SDK backlog review, with help from GitHub Copilot.