Long-running agent sessions exhaust event storage and appear cancelled while CLI remains active

Description

Long-running Copilot CLI project sessions that spawn many subagents can exhaust the remote session event store. Once this happens, session status and handoffs become unreliable: sessions appear inactive or cancelled even though their CLI processes remain alive and may still be executing subagents.

Environment

• Copilot CLI: 1.0.79-5
• OS: Windows
• Workload: multiple long-running project/worktree sessions using custom agents with planner, debugger, impact-analysis, coverage, and review subagents

Reproduction

1. Start a project session that performs a multi-hour workflow with frequent tool calls, planner checkpoints, and nested subagents.

2. Allow the session to accumulate a large event history.

3. Observe repeated exporter failures such as:

   Failed to submit events to Mission Control session …: 409
   {"code":"session_event_storage_exhausted","message":"session event storage exhausted"}
   remote session batch flush failed … "event_count":500
   remote session exporter circuit opened after batch flush failure
   

4. Query the session through the app/runtime status APIs.

Actual behavior

• The project session may lose its active_session_id or appear inactive.
• Background-agent status may report Cancelled or no agents, without a cancellation reason.
• Final handoffs may not arrive.
• Restarting based on this status can create a second writer for the same dirty worktree.
• The underlying CLI process can still be alive, consuming CPU, updating its log, and executing internal subagents after the UI/runtime reports no active work.
• Logs can also report cleanup of many orphaned tool calls, but do not identify a timeout, quota, or other cancellation cause.

Expected behavior

• Event storage should rotate, compact, or start a continuation stream before exhaustion.
• Exporter failure should not make an otherwise-running session unsteerable or misreport its liveness.
• Status should distinguish at least: CLI alive, agent running, agent idle, export disconnected, and task cancelled.
• Cancellation should always expose a reason such as user request, timeout, execution budget, parent teardown, or storage failure.
• The runtime should prevent or clearly warn about concurrent writers when recovery is attempted for a worktree whose original process is still active.

Impact

This makes long-running autonomous work unsafe to recover. Users cannot tell whether work has stopped, and a reasonable restart attempt can cause concurrent edits in the same worktree. Dirty changes were preserved in this case, but reliable coordination required inspecting local process IDs and logs rather than the product status APIs.

Suggested mitigation

Automatically rotate or compact session event history near the storage limit, preserve a local liveness/control channel when remote export fails, and surface a prominent event storage exhausted health state with recovery guidance.

Start by reproducing the multi-hour project session and inspect the exporter failures, runtime status APIs, and local process and session logs described in the report. Compare reported status with the still-running CLI and subagents. Done means storage exhaustion is handled or surfaced clearly, liveness states and cancellation reasons are distinguishable, and recovery cannot create concurrent writers.