mirror of
https://github.com/openai/codex.git
synced 2026-05-03 21:01:55 +03:00
1dd1355df3b4d33fe84de77b8a3efba1ce940d92
8 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
c673e7adb6 |
chore(deps): bump tracing-opentelemetry from 0.31.0 to 0.32.0 in /codex-rs (#8415)
Bumps [tracing-opentelemetry](https://github.com/tokio-rs/tracing-opentelemetry) from 0.31.0 to 0.32.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/tokio-rs/tracing-opentelemetry/releases">tracing-opentelemetry's releases</a>.</em></p> <blockquote> <h2>0.32.0</h2> <h3>Added</h3> <ul> <li>Add configuration for including <code>target</code> in spans (<a href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/222">#222</a>)</li> </ul> <h3>Changed</h3> <ul> <li>OpenTelemetry context activation (<a href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/202">#202</a>) <ul> <li>Trace ID and span ID can be obtained from <code>OtelData</code> via dedicated functions. Note that these will be available only if the context has already been built. (<a href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/issues/233">#233</a>)</li> </ul> </li> <li>Correctly track entered and exited state for timings (<a href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/212">#212</a>)</li> <li>Slightly improve error message on version mismatch (<a href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/211">#211</a>)</li> <li>Remove Lazy for thread_local static (<a href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/215">#215</a>)</li> <li>Update description of special fields and semantic conventions</li> </ul> <h3>Breaking Changes</h3> <ul> <li>The attributes <code>code.filepath</code>, <code>code.lineno</code>, and <code>code.namespace</code> have been renamed to <code>code.file.path</code>, and <code>code.line.number</code>, and <code>code.module.name</code>, to align with the opentelemetry semantic conventions for code. (<a href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/225">#225</a>)</li> <li>Upgrade from opentelemetry to 0.31.0. Refer to the upstream <a href="https://github.com/open-telemetry/opentelemetry-rust/blob/main/opentelemetry-sdk/CHANGELOG.md#0310">changelog</a> for more information. (<a href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/230">#230</a>)</li> <li>Hold onto <code>MetricsProvider</code> in <code>MetricsLayer</code> (<a href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/224">#224</a>)</li> <li>The attribute <code>otel.status_message</code> was changed to <code>otel.status_description</code> to align with the opentelemetry semantic conventions for code. (<a href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/209">#209</a>)</li> <li>Remove the <code>metrics_gauge_unstable</code> feature.</li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/tokio-rs/tracing-opentelemetry/blob/v0.1.x/CHANGELOG.md">tracing-opentelemetry's changelog</a>.</em></p> <blockquote> <h2><a href="https://github.com/tokio-rs/tracing-opentelemetry/compare/v0.31.0...v0.32.0">0.32.0</a> - 2025-09-29</h2> <h3>Added</h3> <ul> <li>Add configuration for including <code>target</code> in spans (<a href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/222">#222</a>)</li> </ul> <h3>Changed</h3> <ul> <li>OpenTelemetry context activation (<a href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/202">#202</a>) <ul> <li>Trace ID and span ID can be obtained from <code>OtelData</code> via dedicated functions. Note that these will be available only if the context has already been built. (<a href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/issues/233">#233</a>)</li> </ul> </li> <li>Correctly track entered and exited state for timings (<a href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/212">#212</a>)</li> <li>Slightly improve error message on version mismatch (<a href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/211">#211</a>)</li> <li>Remove Lazy for thread_local static (<a href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/215">#215</a>)</li> <li>Update description of special fields and semantic conventions</li> </ul> <h3>Breaking Changes</h3> <ul> <li>The attributes <code>code.filepath</code>, <code>code.lineno</code>, and <code>code.namespace</code> have been renamed to <code>code.file.path</code>, and <code>code.line.number</code>, and <code>code.module.name</code>, to align with the opentelemetry semantic conventions for code. (<a href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/225">#225</a>)</li> <li>Upgrade from opentelemetry to 0.31.0. Refer to the upstream <a href="https://github.com/open-telemetry/opentelemetry-rust/blob/main/opentelemetry-sdk/CHANGELOG.md#0310">changelog</a> for more information. (<a href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/230">#230</a>)</li> <li>Hold onto <code>MetricsProvider</code> in <code>MetricsLayer</code> (<a href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/224">#224</a>)</li> <li>The attribute <code>otel.status_message</code> was changed to <code>otel.status_description</code> to align with the opentelemetry semantic conventions for code. (<a href="https://redirect.github.com/tokio-rs/tracing-opentelemetry/pull/209">#209</a>)</li> <li>Remove the <code>metrics_gauge_unstable</code> feature.</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
|
ad7b9d63c3 | [codex] add otel tracing (#7844) | ||
|
|
fa4cac1e6b |
fix: introduce AbsolutePathBuf and resolve relative paths in config.toml (#7796)
This PR attempts to solve two problems by introducing a `AbsolutePathBuf` type with a special deserializer: - `AbsolutePathBuf` attempts to be a generally useful abstraction, as it ensures, by constructing, that it represents a value that is an absolute, normalized path, which is a stronger guarantee than an arbitrary `PathBuf`. - Values in `config.toml` that can be either an absolute or relative path should be resolved against the folder containing the `config.toml` in the relative path case. This PR makes this easy to support: the main cost is ensuring `AbsolutePathBufGuard` is used inside `deserialize_config_toml_with_base()`. While `AbsolutePathBufGuard` may seem slightly distasteful because it relies on thread-local storage, this seems much cleaner to me than using than my various experiments with https://docs.rs/serde/latest/serde/de/trait.DeserializeSeed.html. Further, since the `deserialize()` method from the `Deserialize` trait is not async, we do not really have to worry about the deserialization work being spread across multiple threads in a way that would interfere with `AbsolutePathBufGuard`. To start, this PR introduces the use of `AbsolutePathBuf` in `OtelTlsConfig`. Note how this simplifies `otel_provider.rs` because it no longer requires `settings.codex_home` to be threaded through. Furthermore, this sets us up better for a world where multiple `config.toml` files from different folders could be loaded and then merged together, as the absolutifying of the paths must be done against the correct parent folder. |
||
|
|
f521d29726 |
fix: OTEL HTTP exporter panic and mTLS support (#7651)
This fixes two issues with the OTEL HTTP exporter: 1. **Runtime panic with async reqwest client** The `opentelemetry_sdk` `BatchLogProcessor` spawns a dedicated OS thread that uses `futures_executor::block_on()` rather than tokio's runtime. When the async reqwest client's timeout mechanism calls `tokio::time::sleep()`, it panics with "there is no reactor running, must be called from the context of a Tokio 1.x runtime". The fix is to use `reqwest::blocking::Client` instead, which doesn't depend on tokio for timeouts. However, the blocking client creates its own internal tokio runtime during construction, which would panic if built from within an async context. We wrap the construction in `tokio::task::block_in_place()` to handle this. 2. **mTLS certificate handling** The HTTP client wasn't properly configured for mTLS, matching the fixes previously done for the model provider client: - Added `.tls_built_in_root_certs(false)` when using a custom CA certificate to ensure only our CA is trusted - Added `.https_only(true)` when using client identity - Added `rustls-tls` feature to ensure rustls is used (required for `Identity::from_pem()` to work correctly) |
||
|
|
ec49b56874 |
chore: add cargo-deny configuration (#7119)
- add GitHub workflow running cargo-deny on push/PR - document cargo-deny allowlist with workspace-dep notes and advisory ignores - align workspace crates to inherit version/edition/license for consistent checks |
||
|
|
f7a921039c |
[codex][otel] support mtls configuration (#6228)
fix for https://github.com/openai/codex/issues/6153 supports mTLS configuration and includes TLS features in the library build to enable secure HTTPS connections with custom root certificates. grpc: https://docs.rs/tonic/0.13.1/src/tonic/transport/channel/endpoint.rs.html#63 https: https://docs.rs/reqwest/0.12.23/src/reqwest/async_impl/client.rs.html#516 |
||
|
|
5881c0d6d4 |
fix: remove mcp-types from app server protocol (#4537)
We continue the separation between `codex app-server` and `codex mcp-server`. In particular, we introduce a new crate, `codex-app-server-protocol`, and migrate `codex-rs/protocol/src/mcp_protocol.rs` into it, renaming it `codex-rs/app-server-protocol/src/protocol.rs`. Because `ConversationId` was defined in `mcp_protocol.rs`, we move it into its own file, `codex-rs/protocol/src/conversation_id.rs`, and because it is referenced in a ton of places, we have to touch a lot of files as part of this PR. We also decide to get away from proper JSON-RPC 2.0 semantics, so we also introduce `codex-rs/app-server-protocol/src/jsonrpc_lite.rs`, which is basically the same `JSONRPCMessage` type defined in `mcp-types` except with all of the `"jsonrpc": "2.0"` removed. Getting rid of `"jsonrpc": "2.0"` makes our serialization logic considerably simpler, as we can lean heavier on serde to serialize directly into the wire format that we use now. |
||
|
|
04c1782e52 |
OpenTelemetry events (#2103)
### Title ## otel Codex can emit [OpenTelemetry](https://opentelemetry.io/) **log events** that describe each run: outbound API requests, streamed responses, user input, tool-approval decisions, and the result of every tool invocation. Export is **disabled by default** so local runs remain self-contained. Opt in by adding an `[otel]` table and choosing an exporter. ```toml [otel] environment = "staging" # defaults to "dev" exporter = "none" # defaults to "none"; set to otlp-http or otlp-grpc to send events log_user_prompt = false # defaults to false; redact prompt text unless explicitly enabled ``` Codex tags every exported event with `service.name = "codex-cli"`, the CLI version, and an `env` attribute so downstream collectors can distinguish dev/staging/prod traffic. Only telemetry produced inside the `codex_otel` crate—the events listed below—is forwarded to the exporter. ### Event catalog Every event shares a common set of metadata fields: `event.timestamp`, `conversation.id`, `app.version`, `auth_mode` (when available), `user.account_id` (when available), `terminal.type`, `model`, and `slug`. With OTEL enabled Codex emits the following event types (in addition to the metadata above): - `codex.api_request` - `cf_ray` (optional) - `attempt` - `duration_ms` - `http.response.status_code` (optional) - `error.message` (failures) - `codex.sse_event` - `event.kind` - `duration_ms` - `error.message` (failures) - `input_token_count` (completion only) - `output_token_count` (completion only) - `cached_token_count` (completion only, optional) - `reasoning_token_count` (completion only, optional) - `tool_token_count` (completion only) - `codex.user_prompt` - `prompt_length` - `prompt` (redacted unless `log_user_prompt = true`) - `codex.tool_decision` - `tool_name` - `call_id` - `decision` (`approved`, `approved_for_session`, `denied`, or `abort`) - `source` (`config` or `user`) - `codex.tool_result` - `tool_name` - `call_id` - `arguments` - `duration_ms` (execution time for the tool) - `success` (`"true"` or `"false"`) - `output` ### Choosing an exporter Set `otel.exporter` to control where events go: - `none` – leaves instrumentation active but skips exporting. This is the default. - `otlp-http` – posts OTLP log records to an OTLP/HTTP collector. Specify the endpoint, protocol, and headers your collector expects: ```toml [otel] exporter = { otlp-http = { endpoint = "https://otel.example.com/v1/logs", protocol = "binary", headers = { "x-otlp-api-key" = "${OTLP_TOKEN}" } }} ``` - `otlp-grpc` – streams OTLP log records over gRPC. Provide the endpoint and any metadata headers: ```toml [otel] exporter = { otlp-grpc = { endpoint = "https://otel.example.com:4317", headers = { "x-otlp-meta" = "abc123" } }} ``` If the exporter is `none` nothing is written anywhere; otherwise you must run or point to your own collector. All exporters run on a background batch worker that is flushed on shutdown. If you build Codex from source the OTEL crate is still behind an `otel` feature flag; the official prebuilt binaries ship with the feature enabled. When the feature is disabled the telemetry hooks become no-ops so the CLI continues to function without the extra dependencies. --------- Co-authored-by: Anton Panasenko <apanasenko@openai.com> |