`codex exec` emits no OTel metrics; `codex mcp-server` emits no OTel telemetry at all

Resolved 💬 1 comment Opened Feb 26, 2026 by flavorjones Closed Feb 28, 2026

Summary

The [otel] configuration in ~/.codex/config.toml is only fully respected by
the interactive CLI. Two other entry points have gaps:

| Mode | Traces | Logs | Metrics |
|------|--------|------|---------|
| codex (interactive) | ✅ | ✅ | ✅ |
| codex exec | ✅ | ✅ | ❌ |
| codex mcp-server | ❌ | ❌ | ❌ |

Config

# ~/.codex/config.toml
[otel]
log_user_prompt = true
exporter = { otlp-http = { endpoint = "http://localhost:4318/v1/logs", protocol = "binary" } }
trace_exporter = { otlp-http = { endpoint = "http://localhost:4318/v1/traces", protocol = "binary" } }

Reproduction

codex exec — no metrics

# Run with debug logging
RUST_LOG=debug codex exec "echo hello" -s read-only --json 2>&1 | grep -i opentelemetry
# → 37 lines: traces and logs exported successfully, zero metrics activity

# Confirm via OTLP collector — traces and logs arrive, metrics do not:
# codex_cli_rs (interactive): 50 metrics
# codex_exec: 0 metrics

codex mcp-server — no telemetry at all

RUST_LOG=debug timeout 5 codex mcp-server 2>&1 </dev/null
# Output (complete):
#   stdin reader finished (EOF)
#   /etc/codex/managed_config.toml not found
#   processor task exited (channel closed)
#   stdout writer exited (channel closed)
#
# Zero opentelemetry-sdk log lines. No BatchLogProcessor, no BatchSpanProcessor,
# no export attempts. OTel is never initialized.

Environment

  • codex-cli 0.105.0
  • Linux x86_64
  • OTLP collector: ai-observer (Docker), receiving on localhost:4318

Impact

Any workflow that uses codex exec or codex mcp-server programmatically
(e.g., as an external reviewer in an automated loop) gets incomplete or
zero observability, despite having a working [otel] config.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗