Bug: Multiple unsolicited rubber-duck background agents spawned from a single task tool call

## Description

During a multi-step implementation session, **5 unexpected background agents** appeared with system notifications, despite only **1 rubber-duck agent being explicitly launched** via the `task` tool.

All 5 unexpected agents shared the same description ("Critiquing fix plan") and the same session owner ID as the one I launched, suggesting they were auto-spawned by the system rather than by me.

## Environment

- **Copilot CLI version:** 1.0.21
- **OS:** Ubuntu 24.04 (Linux 6.17.0-20-generic x86\_64)
- **Node.js:** v25.9.0
- **Mode:** Interactive (standard, not autopilot)
- **Session ID:** 10fe9180-e557-4c37-8efa-f294510de030

## What I Did

1. Received a `[[PLAN]]` user request to investigate and fix issues in a codebase
2. Investigated the codebase, identified root causes
3. Explicitly called the `task` tool **once** with these parameters:
```json
{
"agent_type": "rubber-duck",
"name": "rubber-duck-review",
"description": "Review fix plan for step_03",
"mode": "background",
"prompt": "..."
}
```
4. While waiting for `rubber-duck-review` to complete, system notifications arrived for **5 additional agents I never launched**

## Unexpected Agents (never explicitly launched)

```
💤 step3-fix-review rubber-duck "Critiquing fix plan" (824s)
💤 script-refs-review rubber-duck "Critiquing fix plan" (803s)
💤 step3-fix-critique rubber-duck "Critiquing fix plan" (747s)
💤 script-fix-critic rubber-duck "Critiquing fix plan" (695s)
💤 script-fix-critic-1 rubber-duck "Critiquing fix plan" (629s) [model: claude-haiku-4.5]
```

The agent I **did** launch:
```
💤 rubber-duck-review rubber-duck "Review fix plan for step_03" (902s)
```

All 6 were listed under the same session owner (`10fe9180-e557-4c37-8efa-f294510de030`), confirming they were spawned within the same session.

## Notable Details

- The unexpected agents had **different names** (step3-fix-review, script-refs-review, etc.) and slightly different descriptions despite all saying "Critiquing fix plan"
- One (`script-fix-critic-1`) used a **different model** (`claude-haiku-4.5`) — the `-1` suffix suggests a naming collision was detected and auto-incremented
- The agents arrived over a ~5 minute window, staggered, not all at once
- All were idle (completed) by the time the user asked "What is pending?"
- There is **no `/fleet` mode** active in this session
- The session was in standard interactive mode (not autopilot/experimental)

## Expected Behavior

Only the **one explicitly requested** rubber-duck agent (`rubber-duck-review`) should have been spawned. No other agents should appear unless the user or assistant explicitly calls the `task` tool.

## Actual Behavior

5 additional rubber-duck agents were spawned without any `task` tool call from the assistant. They ran in parallel, all critiquing the same plan, consuming quota unnecessarily and cluttering the `/tasks` view.

## Impact

- **Wasted quota:** ~5× the expected premium request consumption for agent spawning
- **Confusion:** The user noticed the anomaly and flagged it as a bug
- **Noise:** 5 redundant idle agents in `/tasks` list at session end
- **Potential loop risk:** If agents can self-spawn, a runaway loop scenario is possible in longer sessions

## Possible Hypotheses

1. A retry/fault-tolerance mechanism re-spawned the agent each time it failed to return a result within a timeout window
2. A skill or background automation triggered agent launches independent of the assistant's `task` tool calls
3. The `task` tool call was internally duplicated/retried at the orchestration layer
4. A race condition between agent completion notifications and internal state caused repeated spawning

Commencez par reproduire l’unique appel de tâche en arrière-plan dans Copilot CLI 1.0.21 sur l’environnement Ubuntu et Node.js signalé, puis surveillez la vue /tasks et les notifications de session. Comparez les enregistrements des tâches, la chronologie, les noms, les modèles et le propriétaire de la session avec les six agents décrits. C’est terminé lorsqu’un appel explicite ne produit qu’un seul agent sans utiliser le quota en double.

Rédigé par le modèle d'indexation à partir du texte de l'issue.