Summary

When a client resumes or reconnects after missing the live event stream, there does not appear to be a documented way in the CLI/SDK to query whether the previous turn already completed successfully.

session.idle appears to be the canonical live "turn is done / session is now idle" signal, but because it is ephemeral and not persisted to events.jsonl, a reconnecting client that missed it has to infer completion from persisted artifacts and coarse session metadata.

Current situation

A resumed client can currently combine:

• live events, if it was attached when they arrived,
• session metadata such as ModifiedTime, and
• persisted artifacts such as ~/.copilot/session-state/<session-id>/events.jsonl.

However, none of the documented SDK APIs seem to provide a direct answer to: did the previous turn already finish, or is it still in progress?

For example:

• GetStatusAsync() exposes CLI/protocol status, not per-session turn state
• ListSessionsAsync() / GetSessionMetadataAsync() expose metadata, not turn completion state
• assistant.turn_end is persisted, but is not a reliable terminal signal because it can occur between tool rounds

Why this matters

For restart/reconnect flows, clients need an authoritative answer to whether the last turn finished cleanly.

Without that, they have to resort to heuristics such as:

1. scanning the tail of events.jsonl,
2. checking file mtime / file growth, and
3. waiting on timeout/watchdog logic.

Those heuristics are inherently unreliable for long-running or tool-heavy turns and can produce both false positives and false negatives.

Requested improvement

Any of the following would solve the underlying problem:

1. Persist a durable completion marker to events.jsonl — either by persisting the final session.idle, or by emitting a dedicated persisted event such as session.turn_complete
2. Expose a documented session/turn status API that a reconnecting client can call after resume
3. Persist a final session status snapshot that can be read after reconnect

The important point is not the exact mechanism; it is that resumed clients need some authoritative, durable completion signal instead of having to guess.

Scope

• Affects the CLI event log under ~/.copilot/session-state/<session-id>/events.jsonl
• Affects SDK/app clients that restore or reconnect sessions after restart, reconnect, or crash recovery

Related downstream tracking issue: PureWeen/PolyPilot#538