Summary
On the prerelease channel (1.0.81-4, 1.0.81-5), the terminal UI stops
consuming runtime events at the moment a turn launches a parallel block of
subagents. The Rust runtime is unaffected and keeps working — subagents
continue making model calls for minutes afterwards and their results are
persisted to the session store — but the terminal never repaints again, accepts
no keyboard input, and scrollback is frozen.
The process is left idle, not spinning: 0 CPU ticks over a 5s sample,
State: S (sleeping), wchan: futex_wait_queue_me, with no busy child
processes. It never recovers and does not exit on its own.
Reproduced 3 times in one evening across independent sessions.
Environment
- Copilot CLI
1.0.81-5 (also seen on 1.0.81-4) — prerelease channel
- Node.js v22.21.1, Linux x64
- Several MCP servers configured (stdio + http)
Steps to reproduce
- Run a workflow where the top-level agent invokes a custom agent via
task.
- Have that custom agent fan out to 2–3 subagents of its own in a single
parallel block (i.e. multiple task calls issued in one turn).
- Observe the terminal at the moment the parallel block is launched.
Total concurrency at failure was 3–4 simultaneous subagents. Sequential
subagent execution has not reproduced it.
Evidence
1. The UI log stops at a turn boundary, always with the same event triple.
The final lines in every frozen session:
[WARNING] useTimeline: skipping unprocessable event type=model.response: Error: Unhandled event type in timeline: model.response
[WARNING] useTimeline: skipping unprocessable event type=model.turn_ended: Error: Unhandled event type in timeline: model.turn_ended
[WARNING] useTimeline: skipping unprocessable event type=model.messages_snapshot: Error: Unhandled event type in timeline: model.messages_snapshot
2. The timeline reducer cannot handle any model.* event. These warnings
are continuous throughout normal operation, thousands per session — one per
runtime event. Counts scale directly with subagent usage (0–260 in ordinary
sessions; 2,504 in a heavy multi-agent session). This looks like event types
emitted by the runtime that the TUI timeline reducer does not know about, i.e.
a skew between the runtime and the UI layer within the same build.
Observed types: model.message, model.turn_started, model.turn_ended,
model.model_call_started, model.model_call_success,
model.captured_assignment_context, model.tool_execution, model.response,
model.messages_snapshot.
3. The runtime continues after the UI dies. Per-call usage rows recorded in
the local session store, cross-referenced with the last UI log line:
| Session |
Last UI event |
Runtime kept working until |
Peak concurrent subagents |
| A |
T+0 |
— |
3 (reached that same minute) |
| B |
T+0 |
T+8min |
4 |
| C |
T+0 |
T+2min or more |
4 (fan-out began T+1min) |
In session B the subagents ran to completion and their results were persisted;
only the UI was lost. copilot --resume <session-id> recovers the session,
which confirms the runtime state is intact.
Expected
The UI keeps rendering and accepting input while subagents run in parallel, or
at minimum fails loudly rather than silently detaching from the event stream.
Actual
UI silently stops consuming events. Terminal appears hung; the only recovery is
killing the process and resuming the session.
Secondary issue: frozen sessions ignore SIGTERM and can leave a spinning zombie
- All four affected processes ignored
SIGTERM and required SIGKILL.
- One process that had begun disposal never exited, logging this once per
second indefinitely (grew its log to 656 KB before it was killed):
[ERROR] SessionClient poll loop error (will retry): Error: Cannot invoke native session after disposal has started
[ERROR] SessionClient background task refresh failed (continuing) [phase=pre-dispatch cursor=… attempts=2
Over one session these accumulated to 10 simultaneous long-lived CLI processes,
none of which could be shut down normally.
Workaround
Force subagents to run sequentially rather than in parallel blocks, and pin to
the stable channel (COPILOT_AUTO_UPDATE=false with a stable version installed
via npm).
Summary
On the prerelease channel (
1.0.81-4,1.0.81-5), the terminal UI stopsconsuming runtime events at the moment a turn launches a parallel block of
subagents. The Rust runtime is unaffected and keeps working — subagents
continue making model calls for minutes afterwards and their results are
persisted to the session store — but the terminal never repaints again, accepts
no keyboard input, and scrollback is frozen.
The process is left idle, not spinning: 0 CPU ticks over a 5s sample,
State: S (sleeping),wchan: futex_wait_queue_me, with no busy childprocesses. It never recovers and does not exit on its own.
Reproduced 3 times in one evening across independent sessions.
Environment
1.0.81-5(also seen on1.0.81-4) — prerelease channelSteps to reproduce
task.parallel block (i.e. multiple
taskcalls issued in one turn).Total concurrency at failure was 3–4 simultaneous subagents. Sequential
subagent execution has not reproduced it.
Evidence
1. The UI log stops at a turn boundary, always with the same event triple.
The final lines in every frozen session:
2. The timeline reducer cannot handle any
model.*event. These warningsare continuous throughout normal operation, thousands per session — one per
runtime event. Counts scale directly with subagent usage (0–260 in ordinary
sessions; 2,504 in a heavy multi-agent session). This looks like event types
emitted by the runtime that the TUI timeline reducer does not know about, i.e.
a skew between the runtime and the UI layer within the same build.
Observed types:
model.message,model.turn_started,model.turn_ended,model.model_call_started,model.model_call_success,model.captured_assignment_context,model.tool_execution,model.response,model.messages_snapshot.3. The runtime continues after the UI dies. Per-call usage rows recorded in
the local session store, cross-referenced with the last UI log line:
In session B the subagents ran to completion and their results were persisted;
only the UI was lost.
copilot --resume <session-id>recovers the session,which confirms the runtime state is intact.
Expected
The UI keeps rendering and accepting input while subagents run in parallel, or
at minimum fails loudly rather than silently detaching from the event stream.
Actual
UI silently stops consuming events. Terminal appears hung; the only recovery is
killing the process and resuming the session.
Secondary issue: frozen sessions ignore SIGTERM and can leave a spinning zombie
SIGTERMand requiredSIGKILL.second indefinitely (grew its log to 656 KB before it was killed):
Over one session these accumulated to 10 simultaneous long-lived CLI processes,
none of which could be shut down normally.
Workaround
Force subagents to run sequentially rather than in parallel blocks, and pin to
the stable channel (
COPILOT_AUTO_UPDATE=falsewith a stable version installedvia npm).