Explicitly trust an insecure (http://) OTLP exporter endpoint (align with VS Code + Copilot Default OTLP Endpoint)

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

1. 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.
2. 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.
3. 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

Start with copilot help monitoring and the OTLP/HTTP endpoint behavior described in the issue. Trace how an http:// endpoint currently disables export, then define and verify the documented opt-in while preserving the secure default; validate with a loopback collector using the example environment variables.