ADORSYS-GIS / ADORSYS-GIS/lightbridge-governance
[Ticket]: Codex and VS Code telemetry needs a second accepted credential after the audience narrows
- Dominant language
- Rust
- Stars
- 1
- Forks
- 2
- Avg merge
- 13h 13m
- Merged PRs (30d)
- 110
Description
### Type
Ticket
### Summary
Once `aiCliOtel`'s OIDC audience narrows to `governance-auth-cli` (#142), Codex and VS Code
Copilot can no longer push telemetry at all. They need a second accepted credential —
either a second receiver/oidc extension trusting `lightbridge-api-key`, or another design
that gives them a refreshable token.
### Why they break
Neither has a credential-helper hook for OTLP headers. Claude Code does
(`otelHeadersHelper`), so `governance-auth otel-headers` can hand it a short-lived
exchanged token on an interval. Codex and VS Code read their OTEL config **once at process
start**, so the only thing that works for them today is the static `--otel-token`: a
long-lived (120d) lightbridge-authz API key carrying `aud: lightbridge-api-key`.
#142 narrows the collector to `aud: governance-auth-cli`, which those keys do not carry, so
they are rejected. This is #84 AC 4, accepted explicitly rather than left undecided.
VS Code is worse off still: it exposes the OTLP endpoint as a *setting* but authentication
**only** via the `OTEL_EXPORTER_OTLP_HEADERS` environment variable, so no file
`governance-auth` writes can supply its credential — `otel.rs::vscode_manual_env` exists
precisely to print the `export` line a human must run.
### Source of truth
- #84 — the parent bug and its AC 4.
- #142 — the audience narrowing that triggers this (currently draft).
- `charts/lightbridge-governance/values.yaml`, `aiCliOtel.oidc` — the comment there records
the same consequence.
- Live evidence: collector logs show `missing or empty header` from clients sending no
credential, alongside `failed to verify id token signature` from Claude Code.
### Not yet decided — this ticket should choose
1. **Second receiver/extension** trusting `lightbridge-api-key` alongside the
`governance-auth-cli` one. Restores today's behaviour. Cost: two trust paths into one
pipeline, and the long-lived-key exposure stays.
2. **Register the API-key audience as an additional client** so one receiver covers both.
Needs checking against ADR-0011 Decision 5 — `aud` is always the requesting `client_id`,
so this may not be expressible.
3. **Accept the gap**: only Claude Code reports telemetry until Codex/VS Code grow a
refresh hook. Cheapest, and honest, but `docs/integrations/ai-client-support-matrix.md`
must then stop claiming those paths work.
### Acceptance criteria
- [ ] A decision is recorded (which option, and why) rather than a receiver being added by
default.
- [ ] If a second credential path ships, an unauthenticated or wrong-audience push still
gets a generic 401 — no detail leaks about which audience would have worked.
- [ ] `docs/integrations/ai-client-support-matrix.md` matches the true end state, whichever
it is. It currently describes Codex/VS Code telemetry as working; after #142 that is
false until this is resolved.
- [ ] Verified by a real OTLP push per client, not by the collector merely starting.
Contributor guide
Assessment
This issue has not been assessed yet.