Support automatic OTel configuration and per-conversation local export in the Copilot app

Feature summary

Let teams configure metadata-only OpenTelemetry for normal app launches, with isolated local output for each conversation, including resumed sessions.

What problem are you trying to solve?

We want to use Copilot's OpenTelemetry data to understand agent workflows—model calls, tool activity, duration and recorded outcomes—while engineers continue using the desktop app normally.

Currently, configuring startup environment variables requires special launch steps. Exports in a terminal do not reliably configure an app opened from the Dock, and repository lifecycle hooks cannot retroactively change the parent CLI process's telemetry configuration.

Local file export also uses a single configured path. Multiple app sessions can therefore share one JSONL destination. Giving each process a different path avoids shared writes, but does not provide one file per logical conversation across subsequent turns and resumes.

We need a supported way to configure this once, with appropriate trust and privacy controls, rather than asking every engineer to maintain shell exports, use a replacement launcher, or repeatedly restart the app.

Our goal is to process OTel locally and send only a small allowlisted summary to our telemetry backend—not upload raw conversations or raw OTLP records.

Proposed solution

Add supported app/project-level OTel settings, ideally also configurable through reviewed and trusted repository configuration.

The app should apply these settings before initializing telemetry in each CLI child. Support exporter selection, destination, protocol and content-capture controls. Respect existing enterprise policies and exporter configuration rather than silently replacing or duplicating them.

For local output, support one private JSONL file per logical conversation:

• Different conversations write to different files.
• Subsequent turns and resumed conversations retain a documented association with the same logical file.
• Conversation identity is not assumed to be the same as a trace ID or process ID.
• Files use safe names and owner-private permissions.

This could be implemented directly in the exporter or through an app-supervised loopback OTLP HTTP receiver that owns all file writes. For the receiver approach:

• Bind only to loopback.
• Parse the actual OTLP format emitted by the bundled CLI.
• Route using explicit gen_ai.conversation.id and verified trace/parent relationships.
• Handle late attribution with bounded buffering.
• Keep ambiguous or process-wide records separate rather than guessing their conversation.
• Handle concurrent requests, duplicate delivery, restarts, write failures and shutdown explicitly.

Keep message-content capture disabled by default. Configuration changes should apply to new sessions without forcing a whole-app restart; clearly indicate when existing sessions cannot adopt them.

Acceptance example: open the app normally, create conversations A and B, then continue/resume A. A and B remain isolated, A's new records remain associated with A, and incomplete or unattributable data is reported honestly.

Workflow impact

This would help teams that primarily use the desktop app and run multiple concurrent or resumed agent sessions.

Engineers could keep their normal workflow, while approved tooling uses standardized OTel data to identify workflow bottlenecks and reliability issues. Teams would no longer need custom launch wrappers, per-engineer environment setup, or a separate reconstruction of similar measurements from SDK events.

Local processing would let teams forward only approved aggregate fields, avoiding unnecessary transmission of prompts, responses, tool arguments, source code or raw session identifiers. The intended use is improving agent workflows, not ranking individual engineers.

Installation context

macOS desktop app, normally launched from the Dock, with multiple local repository/worktree sessions. Requested configuration scope: trusted project/repository settings subject to enterprise policy.

Additional context

Related: https://github.com/github/app/issues/133

That issue requests general OpenTelemetry support. This request adds specific normal-launch configuration, local conversation isolation, resume behavior and privacy requirements.

In a controlled macOS experiment, launching a fresh app process with explicit OTel settings successfully delivered OTLP HTTP JSON to a loopback receiver. A scoped receiver separated two test conversations into private files, and a subsequent turn appended to the same conversation's file.

This demonstrates feasibility, not a supported persistent normal-launch solution or a guarantee of complete/lossless capture. The initial experiment also showed that app restoration can produce telemetry from other restored sessions, so filtering before persistence and clear scope controls matter.

Message-content capture was disabled. Even then, telemetry can contain identifiers and other metadata, so local privacy controls and an explicit outbound allowlist remain necessary.

No private traces, prompts, credentials or repository-specific telemetry records are attached.

No repository files, tests, or entry points are identified; start by locating the app's telemetry initialization and configuration paths, then review related issue #133. Done means supported normal-launch settings, privacy and policy controls, and isolated private files for conversations A and B, with resumed A records remaining associated with A.