Describe the feature or problem you'd like to solve
Add an opt-in to trust an insecure (http://) OTLP exporter endpoint — e.g. a loopback collector at http://localhost:4318 — instead of silently disabling telemetry export.
Proposed solution
With the OTLP/HTTP exporter and an http:// endpoint — including the documented default http://localhost:4318 — the Copilot CLI disables telemetry export rather than sending it. copilot help monitoring states export is disabled "rather than sent in cleartext; startup is not aborted," so the only signal is a process-log warning. There is no environment variable or setting to opt into exporting over an insecure/loopback endpoint. The only local no-TLS path is the file exporter (COPILOT_OTEL_FILE_EXPORTER_PATH); any network path requires an https:// endpoint with a trusted cert.
This deviates from the OpenTelemetry protocol-exporter spec (https://opentelemetry.io/docs/specs/otel/protocol/exporter/), which governs OTLP/HTTP transport security by the URL scheme ("OTLP/HTTP always uses the scheme provided for the endpoint"), scopes OTEL_EXPORTER_OTLP_INSECURE to OTLP/gRPC only, and says SDKs SHOULD default to the http scheme. A spec-compliant OTLP/HTTP exporter pointed at http://localhost:4318 therefore exports over http. The VS Code Copilot extension already does exactly this (its documented default is http://localhost:4318); only the CLI refuses, with no escape hatch.
Request: honor OTEL_EXPORTER_OTLP_INSECURE=true for the http exporter, or add a Copilot-specific COPILOT_OTEL_ALLOW_INSECURE=true / settings toggle, so a user who knowingly targets a loopback collector can export without TLS or the file-exporter indirection. Keep the secure behavior (disabled on http) as the default — the ask is a documented opt-in, not a default change.
Benefit: restores the standard local-observability workflow (a loopback OTLP collector on :4318, which every other OTLP producer supports out of the box) for CLI users, removing the need to either stand up TLS for a localhost endpoint or route through the file exporter.
Example prompts or workflows
- OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318 OTEL_EXPORTER_OTLP_INSECURE=true copilot -p "..." → traces/metrics land in a locally-running OpenTelemetry Collector, same as the VS Code extension.
- A developer running a local Grafana/Prometheus/Tempo stack (collector on :4318) points both their VS Code Copilot extension and the Copilot CLI at the same loopback endpoint and sees unified gen_ai.* / github.copilot.* telemetry — no per-tool cert setup.
- CI or a dev container with an OTLP collector sidecar on localhost captures Copilot CLI GenAI spans without provisioning and distributing TLS certs to every ephemeral environment.
Additional context
Observed on Copilot CLI self-reporting v1.0.80 (macOS, latest update see below); behavior and quoted wording from copilot help monitoring. The VS Code Copilot extension's OTel docs show http://localhost:4318 as the default endpoint with Aspire/Jaeger/Langfuse examples all over plain http and no "http disables export" caveat — so the CLI and extension currently differ on this point.
❯ copilot --version
GitHub Copilot CLI 1.0.80.
Run 'copilot update' to check for updates.
❯ copilot update
Checking for updates...
Checking GitHub for the latest release...
No update needed, current version is 1.0.80, fetched latest release is v1.0.80
Describe the feature or problem you'd like to solve
Add an opt-in to trust an insecure (http://) OTLP exporter endpoint — e.g. a loopback collector at http://localhost:4318 — instead of silently disabling telemetry export.
Proposed solution
With the OTLP/HTTP exporter and an http:// endpoint — including the documented default http://localhost:4318 — the Copilot CLI disables telemetry export rather than sending it. copilot help monitoring states export is disabled "rather than sent in cleartext; startup is not aborted," so the only signal is a process-log warning. There is no environment variable or setting to opt into exporting over an insecure/loopback endpoint. The only local no-TLS path is the file exporter (COPILOT_OTEL_FILE_EXPORTER_PATH); any network path requires an https:// endpoint with a trusted cert.
This deviates from the OpenTelemetry protocol-exporter spec (https://opentelemetry.io/docs/specs/otel/protocol/exporter/), which governs OTLP/HTTP transport security by the URL scheme ("OTLP/HTTP always uses the scheme provided for the endpoint"), scopes OTEL_EXPORTER_OTLP_INSECURE to OTLP/gRPC only, and says SDKs SHOULD default to the http scheme. A spec-compliant OTLP/HTTP exporter pointed at http://localhost:4318 therefore exports over http. The VS Code Copilot extension already does exactly this (its documented default is http://localhost:4318); only the CLI refuses, with no escape hatch.
Request: honor OTEL_EXPORTER_OTLP_INSECURE=true for the http exporter, or add a Copilot-specific COPILOT_OTEL_ALLOW_INSECURE=true / settings toggle, so a user who knowingly targets a loopback collector can export without TLS or the file-exporter indirection. Keep the secure behavior (disabled on http) as the default — the ask is a documented opt-in, not a default change.
Benefit: restores the standard local-observability workflow (a loopback OTLP collector on :4318, which every other OTLP producer supports out of the box) for CLI users, removing the need to either stand up TLS for a localhost endpoint or route through the file exporter.
Example prompts or workflows
Additional context
Observed on Copilot CLI self-reporting v1.0.80 (macOS, latest update see below); behavior and quoted wording from copilot help monitoring. The VS Code Copilot extension's OTel docs show http://localhost:4318 as the default endpoint with Aspire/Jaeger/Langfuse examples all over plain http and no "http disables export" caveat — so the CLI and extension currently differ on this point.