With GitHub Copilot CLI 1.0.83-5 and the Go Copilot SDK v1.0.13, protocol 3,
one SDK worker session emitted an event named model.telemetry. The Go SDK
does not define a typed event with that name and exposes unknown event data
through RawSessionEventData.
Our application deliberately fails closed on uncharacterized events. It stopped
that worker on this event. This is our guard's rejection, not evidence that the
SDK itself rejected an otherwise valid model response. We need to characterize
the event before deciding whether to treat it as an irrelevant projection.
The event appeared in a fresh worker configured for claude-opus-5 with high
effort. Thirty-seven prior worker calls completed in the same application run.
The affected worker had no accepted evidence reads, report or usage observation
before the guard stopped it. The payload was not retained by the guard. A
model-free HTTP 400 response and a synthetic successful Anthropic tool response
both exercised the same CLI/SDK, but neither emitted this event.
Could you clarify:
- The event's schema and trigger conditions in CLI 1.0.83-5.
- Whether it is purely diagnostic, or can carry an error, route change,
truncation, cancellation or another execution-significant state.
- Whether execution-significant states carried by it are also guaranteed to
appear in the typed session, assistant, usage or tool lifecycle events.
- A deterministic local fixture or injected provider response that emits it
without paid inference.
We are keeping our report schema, required-read checks and lifecycle validation
unchanged while investigating. No prompts, response bodies, credentials or private
repository content are needed for this question.
With GitHub Copilot CLI 1.0.83-5 and the Go Copilot SDK v1.0.13, protocol 3,
one SDK worker session emitted an event named
model.telemetry. The Go SDKdoes not define a typed event with that name and exposes unknown event data
through
RawSessionEventData.Our application deliberately fails closed on uncharacterized events. It stopped
that worker on this event. This is our guard's rejection, not evidence that the
SDK itself rejected an otherwise valid model response. We need to characterize
the event before deciding whether to treat it as an irrelevant projection.
The event appeared in a fresh worker configured for
claude-opus-5with higheffort. Thirty-seven prior worker calls completed in the same application run.
The affected worker had no accepted evidence reads, report or usage observation
before the guard stopped it. The payload was not retained by the guard. A
model-free HTTP 400 response and a synthetic successful Anthropic tool response
both exercised the same CLI/SDK, but neither emitted this event.
Could you clarify:
truncation, cancellation or another execution-significant state.
appear in the typed session, assistant, usage or tool lifecycle events.
without paid inference.
We are keeping our report schema, required-read checks and lifecycle validation
unchanged while investigating. No prompts, response bodies, credentials or private
repository content are needed for this question.