Describe the bug
When calling write_agent to send a message to an idle background agent, the tool call appears to not return control back to the assistant's turn until the target agent has actually woken up and started actively running (processing the new message). If the user sends a new message during this window, it gets queued instead of being handled immediately — even though, from the assistant's perspective, only a single lightweight tool call was made.
Observed pattern (2 occurrences in one session):
- Assistant calls write_agent targeting an idle background agent (e.g., asking it to start a new sub-task).
- Assistant's turn appears to hang / user's next message gets queued for an extended period (not just a few seconds).
- User presses Ctrl+C to interrupt and regain control.
- Side effect: the background agent that had just been "woken up" by the write_agent call is found to be in a Cancelled state afterward (confirmed via list_agents ), even though the user did not intend to cancel that specific agent — it seems the Ctrl+C interrupt, aimed at escaping the queue, also tore down whatever background agent had just transitioned into "actively running."
This happened twice with two different background agents in the same session (both times right after a write_agent call woke an idle agent into active work).
Expected behavior:
write_agent (and any similar "dispatch to background agent" tool) should return control to the assistant's current turn immediately after the message is enqueued/delivered, without waiting for the target agent to actually begin processing — so the assistant's turn can end promptly and the user's own next input is never blocked/queued behind a background agent's execution.
Environment:
• GitHub Copilot CLI version: 1.0.70
• Platform: Linux
Additional note: This is a hypothesis based on observed correlation (not confirmed via internal logs/source), but the pattern was consistent across two independent incidents in the same session.
Affected version
No response
Steps to reproduce the behavior
No response
Expected behavior
No response
Additional context
No response
Describe the bug
When calling write_agent to send a message to an idle background agent, the tool call appears to not return control back to the assistant's turn until the target agent has actually woken up and started actively running (processing the new message). If the user sends a new message during this window, it gets queued instead of being handled immediately — even though, from the assistant's perspective, only a single lightweight tool call was made.
Observed pattern (2 occurrences in one session):
This happened twice with two different background agents in the same session (both times right after a write_agent call woke an idle agent into active work).
Expected behavior:
write_agent (and any similar "dispatch to background agent" tool) should return control to the assistant's current turn immediately after the message is enqueued/delivered, without waiting for the target agent to actually begin processing — so the assistant's turn can end promptly and the user's own next input is never blocked/queued behind a background agent's execution.
Environment:
• GitHub Copilot CLI version: 1.0.70
• Platform: Linux
Additional note: This is a hypothesis based on observed correlation (not confirmed via internal logs/source), but the pattern was consistent across two independent incidents in the same session.
Affected version
No response
Steps to reproduce the behavior
No response
Expected behavior
No response
Additional context
No response