Track app-server start in ChatGPT telemetry

[aibrahim-oai]

Why

We want ChatGPT telemetry to receive app-server startup timing as its own signal instead of folding it into thread or turn telemetry. Keeping startup separate makes the later turn timing breakdown cleaner and gives us a direct measure of process start-to-ready latency.

What changed

• add a dedicated codex_app_server_started analytics event and reducer/client plumbing in codex-rs/analytics
• measure startup duration and completion time in codex-rs/app-server/src/lib.rs
• add serialization and reducer coverage for the new event

Verification

• cargo check -p codex-analytics -p codex-app-server -p codex-core
• just fix -p codex-analytics -p codex-core

[aibrahim-oai]

This change is part of the following stack:

• Track app-server start in ChatGPT telemetry #24142 ◀
  • Track thread start in ChatGPT telemetry #24143
    • Track turn timing in ChatGPT telemetry #24144

_{Change managed by git-spice.}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 3ed1c71cec

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Delay startup event until remote control is connected

When the app server is launched as remote-control-only (for example --listen off --remote-control), this records codex_app_server_started immediately after spawning the processor, but start_remote_control only returns a JoinHandle while its initial status is still Connecting and the spawned RemoteControlWebsocket::run performs the actual backend connection afterward (app-server-transport/src/transport/remote_control/mod.rs:168-198). That makes the new startup telemetry undercount start-to-ready latency precisely for the remote-control path, because the event can be sent before the app server is reachable from ChatGPT.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ee60c494da

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Update analytics tests for the startup event

In the app-server v2 analytics tests I checked (thread_start.rs, thread_fork.rs, and thread_resume.rs), wait_for_analytics_payload returns the first /codex/analytics-events/events POST and then looks for codex_thread_initialized. This new unconditional startup POST is emitted before any thread start/resume/fork request, so those tests now see only codex_app_server_started in the first payload and fail instead of reaching the thread event; update the tests/helpers to wait for the specific event type, as wait_for_analytics_event already does.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 50056e7f1d

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Update plugin analytics tests for startup event

With this unconditional startup event, app-server tests that enable analytics now receive codex_app_server_started as the first /codex/analytics-events/events POST before any later plugin action. Fresh evidence in the current tree is that the thread analytics tests were updated to wait for a specific event, but plugin_install.rs's wait_for_plugin_analytics_payload and plugin_uninstall.rs still read the first analytics POST and assert it is codex_plugin_installed/codex_plugin_uninstalled, so those CI tests will fail when the startup payload arrives first.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 4fdc8e8124

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Emit startup telemetry for in-process app-server starts

This call only runs in run_main_with_transport_options, but the main TUI and exec paths start the app server through InProcessAppServerClient (tui/src/lib.rs and exec/src/lib.rs), which reaches in_process::start_uninitialized and creates an analytics_events_client without ever calling track_app_server_started. In those in-process launches the new codex_app_server_started event is never emitted, so the startup telemetry misses a primary production app-server path rather than tracking all app-server starts.

Useful? React with 👍 / 👎.

[rhan-oai]

would be preferable to keep the boundary clean and avoid defining this in the analytics crate and using it in app-server, can we move this timing code into app-server?