Codex Client Analytics

[etraut-openai]

We want to share an upcoming change that we’re planning for the Codex CLI.

We plan to add optional analytics (telemetry) to the Codex CLI. This allows the client to periodically send a small amount of anonymous usage and health data back to OpenAI.

The goal is to:

• Detect when Codex is not working correctly, especially for issues that are visible only on the client side.
• Better understand which CLI features and configuration options are being used, so we can focus our effort on improving the things that matter most.

While we already have visibility into many problems through our server-side analytics, the lack of client-side analytics leaves us with a blind spot.

Here is what we plan to implement.

• Analytics will not include any PII (personally identifiable information).
• The code that collects analytics will be in the open source repo, visible to everyone.
• Analytics will default to enabled, except in jurisdictions where opt-out is required by law.
• You will be able to explicitly disable analytics via a new analytics feature flag.

Please share any questions or concerns.

Thanks for helping us make Codex better!

– The Codex Team

[darinkist]

Thanks for sharing this and for the transparency around the motivation for adding client-side analytics.

I understand that usage data is important to improve reliability and to focus development on what matters most. From a user perspective, I'd personally prefer an explicit opt-in rather than having to actively opt out.

It would also be important to clearly and proactively inform users once a release actually starts collecting data, and to have the official Codex documentation updated at that point.

Q: If I understand the current state (v0.79.0) correctly: the analytics config flag already exists (defaulting to true), but the actual data collection logic is not yet implemented. Is that correct?

Thanks for engaging openly with the community.

[jif-oai]

Yes it is correct

[tagorr]

I have some concerns about the Opt-out approach, especially since many of us work with highly sensitive data. However, I am willing to consider this as a compromise if the following conditions are met:

1. Interactive Prompt: On the first run after the update, the CLI should explicitly ask for permission with an interactive "Yes/No" prompt.
2. Transparency: Since the telemetry code is Open Source, it would be great to have a command (e.g., codex-cli telemetry-preview) to see exactly what data is being packaged for the next transmission.
3. Easy Configuration: Users shouldn't have to use a specific flag every time they run a command. There should be a simple way to toggle telemetry globally within the CLI settings/config once, and have that choice persist.

If these transparency and control features are implemented, it would make the telemetry addition much more acceptable for the community.

[jif-oai]

Hi, thanks for your comment. A few notes on your point:

1. We can study this possibility. Will check with UX and come back on this
2. The full list of metrics we collect will be publicly available. None of those will contain code coming from your codebase. To give you a quick sense of what do we plan to collect for example:

• list of experimental feature used
• number of /review done
• number of approval request approved/refused
• average tool call duration
• ... (I will link the full list here when this is publicly available)

3. This will be a flag in the config.toml

[tagorr]

Thanks for the update!

It’s great to hear you're looking into the Interactive Prompt. Honestly, that would be the best way to handle this, it builds trust right from the start. OpenAI has a good track record of listening to the community, so I’m hopeful you’ll stick to that approach here too.

About the config.toml: that works for me. It would be even better if we could toggle it directly through the CLI's main management menu (where we manage models and skills), just to keep everything in one place.

Looking forward to seeing the final list of metrics!

[etraut-openai]

Thanks for the input.

There are pros and cons to an interactive prompt. While it provides additional transparency, it also results in increased friction and overhead for all users. Many users will simply not take the time to read or understand the question and opt out, which would undermine the goal of collecting analytics to inform product improvement priorities. For these reasons, we've decided not to include an interactive prompt at this time.

We've documented the metrics we're collecting here and provided clear instructions for how to opt out if you prefer. Let us know if you have suggestions for how to improve this documentation.

Enterprise plan admins can choose to disable analytics for all users in their organization using managed config overrides.

As mentioned above, the code that collects metrics is visible for everyone to see in our open-source repo. If you have any questions about specific metrics or want to look at the code that uploads the analytics, you can clone the repo and ask Codex questions about its own source code.

[tagorr]

I understand the concern about friction and the risk of losing valuable data. It’s a common challenge for product teams. Having reviewed the metrics catalog, I agree that the data being collected is technical and doesn't pose a security risk. However, this is more about maintaining user trust and ensuring transparency.

However, as a compromise, what about a simple one-time notification instead of a blocking prompt?

Most users don't track every pull request or commit, so they might never know telemetry was even added. A brief message on the first run after the update, something like:
'Codex now includes anonymous technical metrics to help us monitor system health. No code or sensitive data is collected. You can review the metrics in our documentation or manage this in your config.toml.'
would provide the transparency the community expects without forcing a 'Yes/No' choice that undermines your data collection.

This way, the vast majority will still provide analytics, but we stay true to the open-source spirit by keeping users informed.
What do you think?