OTEL codex.tool_result logs full tool payloads by default

What issue are you seeing?

When OTEL log export is enabled, Codex includes full tool payload bodies in codex.tool_result by default.

In practice, this means arguments and output can contain the actual body content of tool requests/results, such as:

• full apply_patch patch bodies
• shell command arguments
• shell / tool output
• sensitive local file content that happens to flow through a tool call

This was surprising from a privacy / safety perspective. log_user_prompt is explicitly configurable, but tool payload details were effectively default-on.

Here is an example of what I observed in OTEL logs:

{
  "labels": {
    "arguments": "*** Begin Patch\n*** Add File: ...\n+CREATE OR REPLACE VIEW ...\n*** End Patch\n",
    "tool_name": "apply_patch",
    "output": "{\"output\":\"Success. Updated the following files:\\nA ...\\nM ...\\n\",\"metadata\":{\"exit_code\":0,\"duration_seconds\":0.1}}",
    "event.name": "codex.tool_result",
    "success": "true"
  }
}

The important part is that this is not just metadata. It is the actual tool input / output body.

What steps can reproduce the bug?

1. Enable OTEL log export in Codex.
2. Run a tool invocation with a meaningful payload, for example:

• apply_patch
• a shell / exec tool
• any tool that returns multiline output

1. Inspect exported OTEL logs for event.name = "codex.tool_result".
2. Observe that arguments and output include the full tool body by default.

A straightforward reproduction is to run apply_patch with a nontrivial patch body and then inspect the exported OTEL record.

What is the expected behavior?

The default behavior should be metadata-only.

For codex.tool_result, I would expect the default OTEL log payload to contain only metadata such as:

• tool_name
• call_id
• duration_ms
• success
• mcp_server
• mcp_server_origin

Body fields such as the following should only be included via explicit opt-in:

• arguments
• output

For reference, Claude Code appears to have an OTEL_LOG_TOOL_DETAILS setting, and something similar in Codex would make this behavior much easier to understand and reason about.

Additional information

From reading the implementation, this behavior appears to come from tool_result_with_tags() in codex-rs/otel/src/events/session_telemetry.rs, where arguments and output are attached unconditionally.