Request for public API support for Copilot Chat request lifecycle observability

[trickl]

Background / Context

This issue is intended to continue a thread that began in PR #2674 (“Add observability for starting and completing Copilot Chat requests”), which was closed with a request to discuss the approach before implementation:

microsoft/vscode-copilot-chat#2674 (comment)

The PR was closed without discussion, but the underlying capability question - whether and how Copilot Chat request lifecycles should be observable by other extensions - remains unresolved. Note this was my fault for not going about this the right way, I should have started the discussion here first - mea culpa!

---

Problem / Use Case

At present, there is no stable or supported mechanism for extensions or external tooling to observe when a Copilot Chat request:

• starts processing, and
• finishes (successfully or otherwise).

As a result, any integration that needs to react to Copilot Chat activity must infer state indirectly (e.g. via UI state or heuristics), which is brittle and unsupported.

Concrete use cases that are currently blocked include:

• Extensions providing progress or status UI during long-running Copilot Chat requests
• Accessibility tooling that needs to announce or respond to request lifecycle changes
• Agent-style workflows that need to coordinate actions around Copilot Chat request boundaries

My particular use case was to integrate with a push notification extension that could send a notification event to my mobile upon completion.

---

Why This Matters

Copilot Chat is increasingly used for multi-step and long-running interactions. Without an observable request lifecycle:

• Extensions cannot integrate cleanly with Copilot Chat behaviour
• Tooling authors are discouraged from building on top of Copilot Chat
• There is no official way to reason about request progress or completion

The original PR proposed exposing lifecycle hooks (e.g. start / finish events), but was closed before any alignment on whether such observability is desirable or how it should be shaped.

---

Design Question (Not a Proposed Implementation)

The goal of this issue is to understand the intended product and API direction.

Specifically:

1. Is the lack of observable Copilot Chat request lifecycle an intentional product constraint?
2. If not, what kind of API surface would be considered appropriate for exposing this information to other extensions?

Possible directions (purely illustrative, not prescriptive) might include:

• Public event emitters for request lifecycle phases
• Lifecycle metadata exposed via existing APIs
• Subscription-based or observable request tracking

Other designs may be preferable; the key point is whether such observability is in scope at all.

---

Clarification Requested

I’m primarily looking for guidance on:

• Whether exposing Copilot Chat request lifecycle information to extensions is something the team would support in principle
• If so, what general shape or constraints the team would expect for such an API

This issue is intended as a design and capability discussion, not a request to resurrect the original PR as-is.

Thanks!