You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Session event delivery permanently fails after one 120s host-ack timeout ("session host did not acknowledge the <event> event within 120s"); session unusable until resume #5100
In long-running interactive sessions, prompt submission fails with:
Execution failed: Error: Request session.send failed with message: session event delivery failed:
session host did not acknowledge the tool.execution_partial_result event within 120s
After the first timeout, every later event delivery to that session host fails immediately with the same message, and the session accepts no more input. The only way to recover is to exit and run copilot --resume (or /restart).
Related: #5018. It has the same failure that never clears and the same session.send failed ending, but on the permission.requested 5-second path. This report covers general session event delivery with the 120s deadline, and the trigger appears to be the Node main thread becoming unresponsive.
Affected version
GitHub Copilot CLI 1.0.94 (observed). Also seen on 1.0.90–1.0.92 builds, Oct 1–9. Not yet observed on 1.0.95-3.
Steps to reproduce the behavior
Not deterministic. Conditions present in every occurrence:
Start an interactive session (copilot) and work in it for many hours: frequent shell tool calls, subagents, several auto-compactions, and at least one copilot --resume of the same session.
Let the context grow large (model request bodies of ~0.4–2 MB).
Eventually a turn stalls. About 120s later, the next prompt submission fails with the error above, and every later prompt fails the same way until exit and --resume.
Expected behavior
One late acknowledgement shouldn't break event delivery for the rest of the session. Delivery should resume once the host responds, or the session should reconnect automatically without exit and --resume.
The Node main thread shouldn't stall for over 120s in long or large sessions.
Log observations (~/.copilot/logs/process-*.log, several processes):
The event type in the message varies:tool.execution_partial_result, session.usage_record, prompt_cache_break, session.managed_settings_resolved, session.background_tasks_changed. The event named is whichever one was waiting when the deadline passed. tool.execution_partial_result shows up most often because one is sent for each chunk of shell output.
The failure never clears. Only the first failure waits the full 120s. After that, every delivery fails within milliseconds with the identical message, which still names the original event. One process logged it 1,645 times.
Onset example:
19:28:07 [pending_request_flow] Waiting for detached host delivery flush
19:28:44 [pending_request_flow] Detached host delivery flush finished {"acknowledged":true} <- 37s, host already lagging
19:28:46 [event_sink] Native model usage projection started <- sends prompt_cache_break
19:30:46 [pending_request_flow] ... session host did not acknowledge the prompt_cache_break event within 120s
19:30:47 [github_telemetry::node_memory] Node memory snapshot timed out
62 more Node memory snapshot timed out lines followed in that process, so the Node main thread was unresponsive. This isn't a delivery-transport problem.
Affected processes: long-running (15+ hours, resumed sessions), ~1.7 GB of memory. Between stalls, the main thread was idle in kevent, so the stalls come in bursts rather than as a constant spin.
The full logs contain private repository content and can't be shared publicly. I can provide filtered excerpts on request.
More data from two more long-running sessions (macOS arm64). This still happens on 1.0.96-2.
Scale: two sessions, each running since Oct 2 (~100 MB events.jsonl, ~4,000 tool calls, 7–8 resumes each), logged 20 session.errors of this kind. The event named in the message varied: assistant.streaming_delta, assistant.reasoning_delta, tool.execution_partial_result, tool.execution_complete, model.call_finished, session.usage_record, session.background_tasks_changed, session.managed_settings_resolved. Each time, recovery needed --resume.
Onset on 1.0.96-2. The JS host logs a new warning before each stall, then goes silent for longer than the ack deadline:
02:36:02.514 [WARNING] Native session event flush exceeded 10000ms; dispatching the host event copy without the ordering barrier
... no JS-side log lines for 41.7s ...
02:36:44.258 [WARNING] Native session event flush exceeded 10000ms; dispatching the host event copy without the ordering barrier
... no JS-side log lines for 187.2s ...
02:38:47.768 [rust:pending_request_flow] session host did not acknowledge the assistant.reasoning_delta event within 120s
02:39:51.486 [WARNING] Native session event flush exceeded 10000ms; ...
The Rust side kept logging throughout (telemetry, deliveries). Only the Node host stopped responding. This is consistent with the Node memory snapshot timed out lines in the original report (39 more in this process).
Agent work keeps going, unseen. Once delivery has failed, the agent loop keeps running. In one session, the 12 minutes after the failure produced ~6,500 assistant.streaming_delta, ~3,200 assistant.message_delta, and ~170 assistant.message / tool.execution_complete events. Each delivery failed (~14,600 warnings and ~40 MB of logs in 10 minutes), yet the events were still saved to events.jsonl. The UI showed nothing until the next session.send surfaced the error. So the agent's work isn't lost, but the user can't see it, can't steer it, and can't approve anything while it runs.
After the failure:[rust:shared_api::lifecycle] Scheduled queue processing failed; retrying once with the same cached error. The process stays mostly idle (main thread in kevent, ~490–720 MB memory), and the session never recovers on its own.
Activity
ElliotChong-MS commentedon Oct 12, 2026
More data from two more long-running sessions (macOS arm64). This still happens on 1.0.96-2.
Scale: two sessions, each running since Oct 2 (~100 MB
events.jsonl, ~4,000 tool calls, 7–8 resumes each), logged 20session.errors of this kind. The event named in the message varied:assistant.streaming_delta,assistant.reasoning_delta,tool.execution_partial_result,tool.execution_complete,model.call_finished,session.usage_record,session.background_tasks_changed,session.managed_settings_resolved. Each time, recovery needed--resume.Onset on 1.0.96-2. The JS host logs a new warning before each stall, then goes silent for longer than the ack deadline:
The Rust side kept logging throughout (telemetry, deliveries). Only the Node host stopped responding. This is consistent with the
Node memory snapshot timed outlines in the original report (39 more in this process).Agent work keeps going, unseen. Once delivery has failed, the agent loop keeps running. In one session, the 12 minutes after the failure produced ~6,500
assistant.streaming_delta, ~3,200assistant.message_delta, and ~170assistant.message/tool.execution_completeevents. Each delivery failed (~14,600 warnings and ~40 MB of logs in 10 minutes), yet the events were still saved toevents.jsonl. The UI showed nothing until the nextsession.sendsurfaced the error. So the agent's work isn't lost, but the user can't see it, can't steer it, and can't approve anything while it runs.After the failure:
[rust:shared_api::lifecycle] Scheduled queue processing failed; retrying oncewith the same cached error. The process stays mostly idle (main thread inkevent, ~490–720 MB memory), and the session never recovers on its own.