Agent records and metrics need separate controls

Original research record

Agent records and metrics need separate controls

We connect three new Codex changes that separate action records, diagnostic logs and metrics export. A custom OTLP metrics collector can stay enabled when built-in analytics are off. Other changes retain larger tool-call arguments and add review identifiers to debug traces. We infer that an audit should check each record and destination separately. These sources do not show tool arguments being sent to the metrics collector.

We see a new reason to ask exactly what an analytics switch controls. Codex’s source now applies analytics.enabled to its built-in Statsig metrics exporter. An explicitly configured OTLP HTTP or gRPC exporter remains enabled independently. The documented metrics-off setting is otel.metrics_exporter = "none". That setting concerns metrics export; it does not promise that every log, trace or action record disappears. [Exporter change](https://github.com/openai/codex/commit/2c3156adf4c9454f0e01c839669255c6a32b5416)

We connect this with a separate change to executed-tool metadata. It removes fixed 8 KiB per-call and 32 KiB per-output argument limits when the metadata fit the available budget. Message budgets, pending-call limits and direct-record retention limits remain. This changes the evidence a record can preserve; it is not evidence that those arguments become metric fields. [Tool-record change](https://github.com/openai/codex/commit/515c291d875e07faa64e3fa43dc9bbffed8db31f)

A third change adds debug spans that link approval review or background scoring to identifiers such as the thread and tool call. It also records retry details. We infer three audit questions: what action content is retained, which diagnostic output is enabled, and where metrics are exported. They need separate answers. All three changes come from one project, so they are one source-origin cluster rather than independent confirmation of a wider trend. [Review-tracing change](https://github.com/openai/codex/commit/6ac8b1b50b8963a8c1481469bd1aa2b1e938a1d3)

Key points We read the exporter-selection test matrix: custom OTLP exporters remain selected across explicit and default analytics settings; the built-in exporter follows its consent path, while none disables metrics export. These are test definitions, not our runtime measurements. We distinguish action metadata, debug traces and metrics. A larger retained argument does not prove that the argument is included in either a debug span or an OTLP metric. We read the new review span fields and retry details. They can help join related diagnostic events, but do not prove fewer review failures or universal log retention. We would record the software revision, configured exporter and destination, logging level, and retained action data before making a claim that an installation has telemetry off.

What could change this view? We would narrow this view for installations with no custom collector or without these source changes. The new behavior honors an explicitly configured OTLP destination; it does not create one or bypass the built-in analytics choice. The metadata change retains total message and retention limits, so it does not promise a complete unlimited record. Debug output also depends on logging configuration. We have not inspected any user’s settings, captured network traffic or proved which released build contains the changes.

Bottom line We would check retained action content, diagnostic logging and each export destination separately. In the checked source, turning off built-in analytics alone does not disable an explicitly configured custom metrics collector. Verify the effective settings and a bounded runtime test before describing a particular installation as telemetry-free.

How likely is this call? · Three frameworks This signal has no investible bullish or bearish call. A market-direction percentage does not apply. Bayesian · what changed the estimate? We add first-party evidence that custom metrics, diagnostic traces and tool-call metadata have distinct code paths and controls. We have no measured prior or likelihood for any user’s data flow, so we make no numerical update. de Finetti · are the comparisons fair? The three changes come from one repository and concern different channels. They are not independent deployments or equivalent privacy incidents. We do not infer prevalence from their count. Kolmogorov · do the numbers agree? We supply no market-direction probabilities. Byte limits, enabled settings and trace identifiers are not event probabilities. No bullish/bearish/neutral partition or market price basis applies. Horizon, exact deadline, neutral band and price basis: Not applicable. Read the shared method: https://new.ontherice.org/how-otr-works/#probability-framework.

Evidence behind this view We connect OTR Database Data Technology attempts 96 and 97 with three exact Codex source changes. Tool-record limits changed at 20:40:47 UTC on 8 October; review tracing at 21:02:08; metrics exporter behavior at 21:18:24. We reopened the first-party receipts at 22:51:30.325–22:51:34.227 UTC and read the relevant implementation paths. All three share the Codex project as their origin.

What past price moves show Not applicable to market prices. An earlier OTR card examined whether every expected action appeared in the execution record. This view adds the separate control and destination question: what is retained, what is logged and what is exported. It does not treat more complete records as proof that every data channel is disabled.

Evidence against this view We would narrow this view for installations with no custom collector or without these source changes. The new behavior honors an explicitly configured OTLP destination; it does not create one or bypass the built-in analytics choice. The metadata change retains total message and retention limits, so it does not promise a complete unlimited record. Debug output also depends on logging configuration. We have not inspected any user’s settings, captured network traffic or proved which released build contains the changes.

Why the direction changed No market direction or locked forecast changes. The source updates refine the meaning of observability controls. Their repository clocks and our observation clocks remain separate from a software release or website publication.

What people say vs the facts We have not measured public complaints, user settings or outbound traffic. We make no privacy-breach, secret-collection or consent-bypass claim. The first-party source says custom metrics are meant to serve an explicitly configured collector.

How past forecasts performed No deployment sample or resolved prediction set estimates the chance of data leaving a particular installation. We publish no incident probability or forecast accuracy. These code records establish selected behavior, with runtime configuration and actual traffic still untested.