Skip to content

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

Open

Description

@ElliotChong-MS

Describe the bug

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:

  1. 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.
  2. Let the context grow large (model request bodies of ~0.4–2 MB).
  3. 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.

Additional context

Environment: macOS 26.7 (25G229), arm64 (Apple Silicon), Ghostty terminal, zsh.

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.

Activity

  1. added
    area:sessionsSession management, resume, history, session picker, and session state
    and removed on Oct 10, 2026
  2. ElliotChong-MS commented on Oct 12, 2026

    @ElliotChong-MS
    Author

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:sessionsSession management, resume, history, session picker, and session state

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions