›_ Codex Issues
Codex Issues / #17110

Codex Desktop App / codex app-server does not honor project-scoped OTel config in trusted projects

Open 💬 5 comments Opened Apr 8, 2026 by FMnaga
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

Codex 26.325.31654 (0.118.0-alpha.2)

What subscription do you have?

ChatGPT Enterprise

What platform is your computer?

Darwin 24.2.0 arm64 arm

What issue are you seeing?

We observed a difference between Codex CLI and Codex Desktop App regarding OpenTelemetry configuration.

  • Codex CLI can read [otel] settings from a trusted project's .codex/config.toml and successfully send OTel logs.
  • Codex Desktop App (appears to run via codex app-server) does not seem to honor the same project-scoped .codex/config.toml OTel settings.
  • If the same [otel] configuration is added to the user's global ~/.codex/config.toml, Codex Desktop App can send telemetry.

This makes team-wide telemetry difficult in fork-based rollout because global config is a per-user workaround, not a scalable repository-distributed configuration model.

What steps can reproduce the bug?

  1. Create a trusted project with .codex/config.toml containing a valid [otel] configuration.
  2. Confirm that codex exec or Codex CLI reads the project-scoped config and exports OTel logs.
  3. Open the same trusted project in Codex Desktop App.
  4. Use Codex Desktop App normally and check whether OTel logs are exported.
  5. Add the same [otel] settings to the user's global ~/.codex/config.toml.
  6. Restart Codex Desktop App and repeat the same test.

Observed result:

  • CLI: project-scoped OTel works
  • Desktop App / app-server: project-scoped OTel appears not to work
  • Desktop App / app-server: global OTel works

Uploaded thread: 019d6bed-eb78-7cc0-bc0f-6c655af763b7

What is the expected behavior?

Codex Desktop App / codex app-server should either:

  1. honor [otel] settings from a trusted project's .codex/config.toml, consistent with Codex CLI, or
  2. explicitly document that OTel is supported only from global ~/.codex/config.toml.

For team usage, project-scoped telemetry should be officially supported because depending on per-user global config does not scale in fork-based rollout.

Additional information

Please clarify whether this is expected behavior or a bug.

The main product request is:

  • document the current intended scope for OTel config (global only vs project-local), and
  • support project-scoped telemetry in Codex Desktop App / codex app-server for organizational rollout.

Feedback thread ID: 019d6bed-eb78-7cc0-bc0f-6c655af763b7
--

CodexDesktop App: 26.325.31654
Internal Codex binary version: 0.118.0-alpha.2

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 4 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #15993
  • #16984
  • #16696

Powered by Codex Action

FMnaga · 4 months ago

Thanks. I reviewed the potentially related issues, but this does not appear to be the same problem.

I can confirm this is still reproducible on the latest Codex Desktop version available to me: 26.409.20454.

The facts I can confirm are:

  1. AGENTS.md is picked up correctly for the same project.
  2. The project is trusted.
  3. With the same OTel configuration, Codex CLI logs are successfully delivered.
  4. Codex Desktop App usage logs are not delivered.
  5. If the OTel settings are moved to the user-level ~/.codex/config.toml, they work.
  6. When the same OTel settings exist only in the project-scoped .codex/config.toml, Codex Desktop App still does not emit usage logs.

So this seems meaningfully different from the related issues listed above.

Since this is still reproducible in the latest environment, could you please re-investigate this issue and consider a fix on the Desktop side?

At this point, the consistent behavior I can observe is:

  • same machine
  • same project
  • same configuration intent
  • Codex CLI logs are delivered
  • Codex Desktop App logs are not delivered
FMnaga · 4 months ago

Hi @etraut-openai — before anything else, I want to acknowledge that this repository currently has 2.5k+ open issues, and I fully understand it is not realistic for the team to respond to every report promptly. The volume you are dealing with is extraordinary, and I can only imagine how difficult it must be to make priority calls across that many reports every single day.

With that said, I would still like to ask for a minimum of triage attention on this particular issue. It has been open for 2 weeks without any acknowledgment, and in the meantime the org-wide OTel-based usage metering rollout has been effectively stopped for our organization. I am trying to keep the ask as small and specific as possible precisely because I know how stretched the team is.

Still reproducing on the latest Codex Desktop: 26.417.40842 (1851). Same matrix as before — CLI emits OTel, Desktop App does not, when the [otel] block only lives in the project-scoped .codex/config.toml of a trusted project.

Why this is urgent for us. We distribute .codex/config.toml through a single repo fork to roll telemetry out to the entire QA organization. The global-config workaround does not scale — it requires every engineer to hand-edit ~/.codex/config.toml, which breaks our clone-and-go model. As a result we currently have no reliable visibility into actual Codex usage across the org, which directly impacts capacity planning and the business case for continued rollout.

Minimal ask. I am not asking for an immediate fix — I am asking for initial investigation and triage clarity:

  1. Can this be looked at and assigned, so we have a visible owner to track progress against?
  2. Is project-scoped [otel] in Desktop / app-server intended to be supported, a known gap, or explicitly out of scope?
  3. If it is intentionally global-only, an explicit statement in docs would let us pivot our rollout strategy instead of continuing to wait.

Please let me know what additional information would help move this forward, and I will provide it.

FMnaga · 4 months ago

@etraut-openai — thank you for picking this up so quickly. Seeing PR #18725 ("Reload app-server OTel from thread config") opened and iterated on within a few hours was genuinely encouraging, and I appreciate the effort that went into it.

I noticed the PR was closed unmerged the same day. I understand there may have been reasons to close it as-is. If a replacement or follow-up is in flight, no need for details if it's too early to share — even a brief status signal like "working on it", "rethinking the approach", or "deprioritized for now" would help us plan on our side, since this is still blocking our org-wide rollout.

Thanks again.

lukaemon · 3 months ago

Adding a related data point from a local OTLP receiver: with Codex CLI 0.128.0, project-scoped .codex/config.toml can export codex.turn.token_usage over OTLP HTTP JSON. The token metric arrived as an OTLP histogram, with token counts in histogram.dataPoints[].sum and token_type attributes like input, cached_input, output, reasoning_output, and total.

The remaining rollout blocker for us is the config-scope distinction described here: terminal/exec telemetry works from project config, but desktop/app-server coverage still needs project-scoped support or clearer documentation. Once desktop/app-server honors trusted-project OTel config, downstream local receivers can keep a shadow lane and compare it against local SQLite before promotion.