From b20dd3218922075a181438b94ae6278b8e66c96f Mon Sep 17 00:00:00 2001 From: atlas Date: Sat, 27 Jun 2026 16:05:03 +0200 Subject: [PATCH] docs(#2023): mark otel.headersCredential as not-yet-wired (argus review) The option description still claimed the credential is loaded via systemd LoadCredential, but this PR removed that path. Clarify that the option is currently inert (only the unauthenticated OTEL export is implemented) and that runtime header injection is a planned follow-up, so configuring it doesn't silently no-op without explanation. --- nix/templates/harness-base.nix | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/nix/templates/harness-base.nix b/nix/templates/harness-base.nix index 13a2f415..ba88db05 100644 --- a/nix/templates/harness-base.nix +++ b/nix/templates/harness-base.nix @@ -264,12 +264,18 @@ in internal = true; description = '' Absolute path to an operator-provided secret file whose contents - become `OTEL_EXPORTER_OTLP_HEADERS` (e.g. - `Authorization=Bearer `). Loaded via systemd - `LoadCredential` into the unit-private credential store at - runtime, so the token is never copied into the nix store or - exposed in the process argv. Host-driven via + would become `OTEL_EXPORTER_OTLP_HEADERS` (e.g. + `Authorization=Bearer `). Host-driven via `services.hyperhive.otel.headersCredential`. + + **Not yet wired up.** OTEL config now ships through the managed + claude settings json (`/etc/claude-code/managed-settings.json`), + which is world-readable, so a secret auth header can't be baked + into it. Setting this option currently has no effect — the + unauthenticated export path is the only one implemented. A + follow-up will inject the header at runtime (e.g. the harness + writing it into the agent's `0600` `~/.claude/settings.json`), + keeping it out of the nix store and the world-readable file. ''; };