CLI 1.0.103: persistent session-lock timeouts and unresponsive tasks amid host event acknowledgement failures #5253

A long-lived Copilot CLI session becomes largely unresponsive. Opening/refreshing tasks shows:

Failed to refresh tasks: Error: session lock unavailable during is_session_generation_current: acquisition timed out

The process stays alive, and some nested tool activity continues, but the UI/event reader repeatedly fails to acquire the session lock.

Environment

• macOS 27.0.1 (26A434), Apple silicon, 32 GiB RAM.
• Loaded package @github/copilot 1.0.103, verified using package.json, loaded runtime.node path and session.start metadata. The executable's Homebrew directory is still named 1.0.96; this is not the loaded package version.
• Process uptime around 30 hours. Session created October 23; diagnosis October 25, 2026.
• Multiple custom workflow extensions and substantial subagent activity. Seven live extension children. No extension has been established as the cause.
• Initial session metadata: gpt-5.6-luna, medium reasoning, long_context. This does not establish the model active at failure.

Observed behavior

The retained logs cover 2026-10-25 13:26:25.472–15:26:51.503 UTC. Their first line is already a failure; the initiating error has rotated out.

These categories overlap and must not be summed as distinct failures. Lock timeouts recur roughly once a second in the latest tail. No held_by or session read lock unavailable diagnostic was present in the retained main-process logs.

The installed JS SessionClient poll loop catches eventLog.read failures, logs “will retry”, waits and loops. The underlying lock ownership remains unknown; this is not yet a proven deadlock.

Sanitized log excerpts

The following excerpts preserve timestamps, source filenames and line numbers. Session, run, workflow and label values use consistent pseudonyms. Non-allowlisted text is removed, including prompts, tool payloads, paths and credentials.

process-1792833427506-51062.1.log:L1 2026-10-25T13:48:30.453Z [WARNING] [rust:copilot_runtime::session::pending_request_flow] pending-request event was not delivered to the session host {"error": "GenericFailure, session event delivery failed: session host did not acknowledge the assistant.reasoning_delta event within 120s"}
process-1792833427506-51062.1.log:L39 2026-10-25T13:48:30.777Z [ERROR] SessionClient poll loop error (will retry): Error: session lock unavailable during is_session_generation_current: acquisition timed out
process-1792833427506-51062.1.log:L41 2026-10-25T13:48:31.076Z [WARNING] [rust:otel] dropping OTel tool facts: pending call limit exceeded
process-1792833427506-51062.1.log:L47 2026-10-25T13:48:31.091Z [WARNING] [rust:events_engine::host_delivery] event was not delivered to its registered session host {"error": "GenericFailure, session event delivery failed: session host did not acknowledge the assistant.reasoning_delta event within 120s"}
process-1792833427506-51062.1.log:L595 2026-10-25T13:49:02.682Z [ERROR] SessionClient.registerInterest(subagent.started) failed (will fall back to "no consumer" path): Error: session lock unavailable during is_session_generation_current: acquisition timed out
process-1792833427506-51062.1.log:L596 2026-10-25T13:49:02.682Z [ERROR] SessionClient.registerInterest(subagent.completed) failed (will fall back to "no consumer" path): Error: session lock unavailable during is_session_generation_current: acquisition timed out
process-1792833427506-51062.1.log:L597 2026-10-25T13:49:02.682Z [ERROR] SessionClient.registerInterest(subagent.failed) failed (will fall back to "no consumer" path): Error: session lock unavailable during is_session_generation_current: acquisition timed out
process-1792833427506-51062.4.log:L1 2026-10-25T13:26:25.472Z [ERROR] [rust:workflow_engine::workflow] Workflow schema subagent preparation failed {"run_id": "<run-1>", "workflow_name": "<workflow-1>", "stage": "turnContext", "error": "session event delivery failed: session host did not acknowledge the assistant.reasoning_delta event within 120s"}
process-1792833427506-51062.4.log:L8 2026-10-25T13:26:25.487Z [ERROR] [rust:workflow_engine::workflow] Workflow subagent resolved to null after a result-quality failure {"run_id": "<run-1>", "workflow_name": "<workflow-1>", "label": "<label-1>", "error": "session event delivery failed: session host did not acknowledge the assistant.reasoning_delta event within 120s"}
process-1792833427506-51062.4.log:L23919 2026-10-25T13:28:05.342Z [ERROR] [rust:workflow_engine::workflow] Workflow subagent preparation failed {"run_id": "<run-3>", "workflow_name": "<workflow-2>", "stage": "turnContext", "error": "session event delivery failed: session host did not acknowledge the assistant.reasoning_delta event within 120s"}
process-1792833427506-51062.log:L35747 2026-10-25T15:26:49.483Z [ERROR] SessionClient poll loop error (will retry): Error: session lock unavailable during is_session_generation_current: acquisition timed out
process-1792833427506-51062.log:L35748 2026-10-25T15:26:50.493Z [ERROR] SessionClient poll loop error (will retry): Error: session lock unavailable during is_session_generation_current: acquisition timed out
process-1792833427506-51062.log:L35749 2026-10-25T15:26:51.503Z [ERROR] SessionClient poll loop error (will retry): Error: session lock unavailable during is_session_generation_current: acquisition timed out

Other observations

• Session events.jsonl: 5,861,848,244 bytes (5.46 GiB). Session workflow/task DB: 50,798,592 bytes. A preserved copy passes SQLite quick_check.
• Main process RSS around 1.08 GiB in one sample. CPU was 5.7% at that point, not a sustained profile.
• Two lsof snapshots show 932 then 933 CLOSED TCP sockets, and 1,072 then 1,073 numeric FDs. This is suspicious retention, not proof of a leak or FD exhaustion; no EMFILE was established.
• System swap used about 33 GiB; memory_pressure -Q reported 41% free. Disk had about 25 GiB available. These may affect responsiveness but do not identify the lock holder.
• Background nested-tool events continued during the lock errors. It is unsafe to assume all work is stopped simply because the task UI is stuck.

Reproduction status

Observed workload, not a minimal deterministic repro:

1. Run/resume a long-lived interactive session with custom workflow extensions and repeated subagent work.
2. Allow substantial event history to accumulate over many hours.
3. Open/refresh tasks after responsiveness degrades.
4. Observe the lock timeout and recurring event-reader errors.

Expected: the UI remains responsive, or recovers from a failed event-delivery operation without permanently losing access to the session.

No restart, lock deletion, debugger attachment or extension-isolation experiment had been performed when the evidence was captured, to preserve the running work and state.

What would help investigate

• Native lock owner operation, acquisition time, hold duration, session correlation and waiter on every timeout.
• Check whether an event acknowledgement wait or workflow preparation/teardown retains a session lock across the 120s timeout.
• Bound repeated event-delivery failures so they do not rapidly rotate away the initiating evidence.
• A supported state-preserving recovery path for the task UI/event reader when background work is still live.

Possibly related: microsoft/vscode#341533, which concerns a different runtime/version and is not established as the same bug.

Full sanitized logs are attached in the follow-up comment: copilot-sanitized-logs.zip. The archive contains five retained main-process log segments with original line ordering, timestamps and source line numbers: 182,854 allowlisted runtime-error lines and 243 explicitly redacted lines, plus aggregate counts and a per-minute timeline. Identifiers are pseudonymized; prompts, tool payloads, credentials and private paths are excluded. Private originals and session-state backups have not been uploaded.