workflow-agent-id-synthesis: marker catalog stale since 2.1.177 — zero derived ids in 6 weeks, and the canary reports the wrong CC version

[vsits-proxy-builder]

Summary

workflow-agent-id-synthesis has produced zero derived agent ids since it shipped. Every derivation attempt emits a drift canary instead, and nothing noticed because no consumer reads the field yet.

Measured on the maintainer's host:

signal	count
workflow-derivation events, all sources	3,747
…that produced an agent id	0
…that were drift_canary	3,747 (100%)
usage.jsonl rows with agent_id populated	0 / 176,344
requests carrying canonical x-claude-code-agent-id	38 / 121,685 (0.03%)

Canary window: 2026-06-16 → 2026-07-29, continuous. So usage-log's agent attribution (CACHE_FIX_USAGE_LOG_AGENT_ID=on) has been silently inert for ~6 weeks, and the drift-canary early-warning signal has been firing correctly the entire time with nobody consuming it.

Likely cause: catalog targets a CC version no longer in use

proxy/workflow-markers.mjs currently carries markers discovered against CC 2.1.177 (cc_npm_sha256: ff41753…, discovered 2026-06-13).

Live traffic on this host:

2084  claude-cli/2.1.220
 646  claude-cli/2.1.201

Neither is 2.1.177. The marker strings were extracted from a binary that is now 40+ patch versions behind, and the catalog's own header anticipates exactly this: "Future marker drift is tracked manually via cc-watch's drift canary signal." The signal worked. The manual follow-up never happened.

Secondary bug: the canary reports the wrong version

Every canary records cc_version: "2.1.177" — but that is CC_VERSION_AT_DISCOVERY, a hardcoded constant (proxy/extensions/workflow-agent-id-synthesis.mjs:132,166), not the version of the client that made the request.

That is actively misleading for the purpose the field exists to serve. An operator reading these events would conclude the drift is happening on 2.1.177, when in fact 2.1.177 is the version the catalog was built against and no live client is running it. The canary should record the requesting client's version (available from the user-agent header, e.g. claude-cli/2.1.220), ideally alongside the discovery version so the mismatch is visible at a glance.

Without that, the canary cannot answer the one question it exists to answer: which CC version broke the catalog?

Impact

• Today: none on cost or correctness. Nothing consumes agent_id, and the synthesis extension is careful — it never mutates headers or body, and a non-match is a clean no-op.
• Imminent: the burn-attribution work in directive: session-budget-breaker burn attribution + early warning (refs #258) #270 wants per-agent attribution. That directive has already been revised to treat agent id as opportunistic rather than assumed (see the measurements above), but agent-level attribution stays unavailable until this is fixed.
• Ongoing: ~3,700 log events with no actionable content, and a broken early-warning signal that will not warn about the next drift either.

Suggested fix

1. Re-discover markers against a current CC build (2.1.220), following the marker-discovery gate in docs/directives/proxy-workflow-agent-id-synthesis.md. Per that directive's design, marker_id stays stable across marker-text evolution, so derived ids remain comparable — add a new catalog entry rather than editing the 2.1.177 one.
2. Fix the canary's version field to report the requesting client's version, keeping cc_version_at_discovery as a separate field.
3. Consider a throttled operator-visible warning when the canary rate stays at 100% over some window. A silent early-warning signal that nobody reads is not an early warning; 6 weeks of 100% canaries should have surfaced without someone going looking.

Consider also whether the canary should record why no marker matched (e.g. system prompt present but no fragment matched, vs. no system prompt at all) — that would make the next re-discovery considerably cheaper.

Found while verifying an agent-id availability claim for #270.

— Proxy Builder