Background agents are cancelled when a new user turn emits user.abort
- Langage dominant
- Shell
- Étoiles
- 11.2k
- Forks
- 1.9k
- Merge moyen
- 14 h 16 min
- PR mergées (30 j)
- 6
Description
### Describe the bug
Submitting a new user turn can send `notifications/copilot` -> `user.abort` to the active turn and cancel background subagents launched by that turn. The agents then appear as `cancelled` in the background-agent list, and their IDs later become unreadable after the aborted turn is garbage-collected.
This prevents the intended orchestration workflow where long-running background agents continue working while the user asks unrelated questions in the main session.
### Affected version
GitHub Copilot CLI 1.0.71-1
### Steps to reproduce the behavior
1. Start two or more native task agents in `background` mode for long-running work.
2. Confirm that the agents are running.
3. Submit another user message to the main session while the agents are still running.
4. Inspect the background-agent list.
5. Observe that agents associated with the previous turn are marked `cancelled`; after turn cleanup, reading their IDs can return `Agent not found`.
The behavior reproduced in two separate waves in one session. Repository worktrees and partial edits survived, but the agents had to be relaunched manually with reconstructed context.
### Expected behavior
Per [Steering agents in GitHub Copilot CLI](https://docs.github.com/en/copilot/how-tos/copilot-cli/use-copilot-cli/steer-agents), a new user message should steer the active task rather than implicitly trigger a full abort.
Background agents should continue running unless the new instruction explicitly cancels them or makes their assigned work obsolete. Unrelated background work should survive the new parent turn and remain readable.
If the CLI cannot preserve background agents across a new user turn, it should warn before submission that the message will cancel them and retain a resumable checkpoint for each cancelled agent.
### Additional context
- macOS on Apple Silicon
- The cancellation was not caused by Computer Use interruption, model unavailability, agent duration limits, or session compaction.
- Runtime logs correlated both cancellation waves with explicit `user.abort` notifications.
- For comparison, equivalent workflows in the GitHub Copilot desktop app and OpenCode 1.17.15 preserve background tasks across ordinary new user messages. This is supporting behavioral context; the Copilot CLI steering documentation above remains the expected-contract basis.
- This is related to, but distinct from, https://github.com/github/copilot-cli/issues/3344: in this case the new turn proceeds, but prior background agents are cancelled.
- Partial filesystem work persisted, so relaunching agents was possible, but parent-side progress and agent conversation state were lost.
Guide de contribution
Ouvrir le guide de contribution
Piste de recherche
Commencez par reproduire le workflow avec deux agents d’arrière-plan ou plus et examinez les journaux d’exécution à la recherche d’événements notifications/copilot user.abort pendant un nouveau tour utilisateur. Suivez le traitement de cette notification et le nettoyage du tour ; c’est terminé lorsque les agents d’arrière-plan non concernés continuent de s’exécuter et restent lisibles, ou reçoivent un avertissement et des checkpoints reprenables avant l’annulation.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- shell
- Domaine
- cli
- Type d'issue
- Bug
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Activité
- Calme
- Clarté
- Plutôt claire
- Accessibilité débutants
- 48/100