Repository navigation
Description
What variant of Codex are you using?
App
What feature would you like to see?
Problem
Codex's OTEL config lets you set environment, span_attributes (per-span), and exporter targets, but there's no way to attach custom resource-level attributes to the telemetry Codex emits. Resource attributes apply to every signal (logs, traces, and metrics) coming from a process, and are the standard OTEL mechanism for tagging where telemetry came from — deployment tier, team ownership, data classification, cost-center, etc. — as opposed to span_attributes, which describe individual spans.
Today the only resource attributes Codex sets are the built-ins: service.name, service.version, env, and (for logs) host.name. Operators running Codex across multiple teams/environments/security tiers have no way to distinguish that telemetry downstream (e.g. in their OTEL collector or backend) without external correlation.
Proposed solution
Add a resource_attributes map to [otel] config that is merged into the resource for all three signal types, without being able to override the built-in attributes:
[otel]
environment = "prod"
exporter = "otlp-http"
[otel.resource_attributes]
"deployment.security.info_classification" = "secret"
"deployment.team.name" = "codex"
This would resolve to a BTreeMap<String, String> on OtelConfig, threaded through OtelSettings, and merged into the Resource built for the logs/traces provider and the metrics MeterProvider. Built-in keys (service.name, service.version, env, host.name) would take precedence over user-supplied values with the same key, so a misconfigured resource_attributes entry can't spoof or corrupt the attributes Codex relies on for its own telemetry pipeline.
Implementation outline
I have a working implementation and I'm happy to open a PR if the team is interested:
codex-rs/config/src/types.rs — resource_attributes: Option<BTreeMap<String, String>> on OtelConfigToml / OtelConfig
codex-rs/core/config.schema.json — schema entry for the new field
codex-rs/core/src/config/otel.rs, codex-rs/core/src/otel_init.rs — resolve and thread the field through to OtelSettings
codex-rs/otel/src/resource_attributes.rs (new) — shared build_resource_attributes() helper used by both the metrics client and the logs/traces provider, which inserts built-ins first and filters user-supplied keys that collide with them
codex-rs/otel/README.md — documents the new field
Test coverage: a config round-trip test in codex-core, a unit test on the merge/override-protection logic, and an integration test against an in-memory metrics exporter confirming the resource is actually populated on export
Additional information
No response
Activity
JSap0914 commentedon Jul 4, 2026
I implemented this on a fork branch, but GitHub rejected PR creation for this repo with:
Branch: https://github.com/JSap0914/codex/tree/feat/otel-resource-attributes-30987
Commit: 227fe1b (
feat(otel): support custom resource attributes)What changed:
[otel.resource_attributes]to the config model and regeneratedcodex-rs/core/config.schema.jsonOtelSettingsservice.name,service.version,env,host.name, plus signal-specific built-ins already emitted by Codex) over configured valuescodex-rs/otel/README.mdVerification run:
cargo test -p codex-otel resource_attributes --libcargo test -p codex-otel configured_resource_attributes_are_exported_with_metricscargo test -p codex-otelcargo test -p codex-core load_config_applies_otel_trace_metadata --libcargo test -p codex-core load_config_drops_invalid_otel_trace_metadata_entries --libcargo test -p codex-core config_schema_matches_fixture --libcargo test -p codex-core otel --libcargo check -p codex-otel -p codex-core -p codex-windows-sandboxDocument Codex resource_attributes as forward-declared (openai/codex#…
chore(codex): drop the unsupported otel.resource_attributes key