Send Claude Code and Codex Telemetry to Safeguard With OTLP

To see what Claude Code and Codex are doing on your engineers' machines, turn on the OpenTelemetry export that both tools already ship, point it at one OTLP over HTTP endpoint with a write-only token, and leave prompt and tool content logging off. Claude Code is configured with standard OTEL_* environment variables, ideally pushed through managed settings so developers cannot redirect it. Codex is configured in the [otel] table of ~/.codex/config.toml. Both send over http/protobuf, both can carry a bearer token in a header, and neither needs your Anthropic or OpenAI API key to do it.

This post walks through the whole job as a platform or security engineer would do it: what each tool emits, what the logging standards ask you to capture, how to roll the configuration out to a fleet, how to keep content out of the pipeline, and how to check it worked. Safeguard enters later, at the point where you need somewhere to send it.

Key takeaways

• Claude Code and Codex both export OpenTelemetry on an opt-in basis. Nothing leaves a machine until you configure an exporter.
• Claude Code sends metrics and events (logs). Codex sends structured log events, and metrics when its metrics pipeline is on. Both record prompt length rather than prompt text by default.
• Use OTLP over HTTP (http/protobuf or http/json) when the receiver only answers HTTP/1.1. gRPC needs HTTP/2 end to end.
• For Claude Code, set the exporter variables in managed settings. Anthropic's docs say a repository's own settings files cannot turn telemetry on or redirect it, and that managed endpoint and header values remove conflicting developer values at startup.
• For Codex, put the exporter in [otel] with the full /v1/logs URL, and keep log_user_prompt = false.
• Issue one write-only ingest token per fleet or team, rotate it on your normal credential schedule, and keep content logging off unless a written policy allows it.
• Safeguard's OpenTelemetry (OTLP) integration (GA) receives logs, metrics and traces over OTLP/HTTP from Claude Code, Codex or any OpenTelemetry Collector. It is switched on per workspace.
• Claude Code and Codex telemetry becomes AI agent events, AI Detection and Response (AIDR) detections in Detection and Response (GA) and events in Security Operations (GA). Credentials in kept values are redacted on arrival.
• AI agent discovery (GA), MCP Guardrail (GA), AI Gateway (GA) and policies and gates (GA) are the in-path and pipeline controls that sit beside this after-the-fact view.

The situation

The request usually arrives one of three ways. An audit sample asks who ran which command on which repository, and the honest answer for coding agents is "we do not know". A security lead reads that agent sessions can run shell commands, call MCP servers and edit files with a developer's credentials, and asks for the same visibility you have for CI runners. Or finance asks what the agent seats cost per team, and the only data is an invoice.

All three have the same root: coding agents run on laptops and in cloud sessions that your existing log pipeline never sees. The endpoint agent sees a process tree. The SIEM sees nothing. The vendor console shows usage, but not in your systems and not joined to anything else.

The good news is that both vendors already did most of the work. Claude Code and Codex each emit OpenTelemetry, the open standard for traces, metrics and logs. The job is configuration, fleet rollout and a decision about content. A bad week looks like this: telemetry goes on for a pilot team with OTEL_LOG_USER_PROMPTS=1 set "for debugging", prompts that contain customer data and pasted credentials land in a general purpose log store with a year of retention, and nobody owns the token that sends it. The rest of this post is about avoiding that week. If you are still deciding whether to allow these agents at all, start with our governance guide for AI coding agents and the practical Claude Code security guide.

What the standards ask you to log

None of the logging standards mention coding agents by name. They do not need to. An agent session that runs commands with a developer's access is a user session with an automation layer on top, and the existing audit controls apply to it.

NIST SP 800-53 Rev. 5, the AU family

The audit and accountability (AU) family in NIST SP 800-53 Rev. 5 is the control catalogue behind FedRAMP baselines and many other US programmes. The controls that bear on agent telemetry:

SI-4 System Monitoring sits beside these and asks you to monitor for attacks, indicators of attack and unauthorised use. For an agent fleet, that is the difference between "we collect events" and "someone is told when an agent runs something it should not".

CISA and partner guidance on event logging

"Best Practices for Event Logging and Threat Detection" (21 August 2024) was developed by the Australian Signals Directorate's ACSC with CISA, the FBI, the NSA and partner agencies in several other countries. CISA's page describes it as a baseline for event logging best practices, written with resourcing constraints in mind. It treats logging as something you plan, centralise and protect, not something you switch on and forget.

For coding agents, the practical reading is simple. An agent that runs curl, git, a package manager and a shell uses the same tools an intruder living off the land would use. You will not spot misuse from the process list alone; you need the agent's own record of what it decided to run and why it was allowed, collected centrally and protected from the people it describes.

OWASP Top 10 for LLM Applications 2025

The OWASP GenAI Security Project's 2025 list names the risks that make agent telemetry worth having. LLM06:2025 Excessive Agency covers damaging actions taken in response to unexpected, ambiguous or manipulated model output; OWASP names excessive functionality, excessive permissions and excessive autonomy as the usual root causes. LLM01:2025 Prompt Injection covers input that changes the model's behaviour in ways nobody intended. LLM02:2025 Sensitive Information Disclosure covers data leaking through the model's inputs and outputs.

Telemetry does not prevent any of these. What it gives you is evidence: which tools an agent was allowed to call, which it actually called, which MCP servers it connected to, and whether a human approved each step or the configuration did. It also cuts the other way. If you log prompt text, the log store itself becomes a place where LLM02 can happen, which is why the content decision later in this post matters.

This post interprets public standards for engineering purposes. It is not legal, regulatory or audit advice; your auditor or counsel decides what your obligations are.

What Claude Code and Codex actually emit

Everything in this section comes from Anthropic's and OpenAI's own documentation, read on 25 October 2026. Both vendors change these schemas between releases, so check the pages in the Sources list against the version your fleet runs.

Claude Code

Anthropic's monitoring page describes three signals. Metrics are exported as time series through the standard metrics protocol. Events are exported through the logs protocol. Distributed traces are a separate opt-in that needs extra variables and is not part of the basic setup.

Telemetry is off until CLAUDE_CODE_ENABLE_TELEMETRY=1 is set, and each signal needs its exporter selected, for example OTEL_METRICS_EXPORTER=otlp and OTEL_LOGS_EXPORTER=otlp. By default Claude Code exports metrics every 60 seconds and logs every 5 seconds; OTEL_METRIC_EXPORT_INTERVAL and OTEL_LOGS_EXPORT_INTERVAL change those in milliseconds.

Every metric and event carries a set of standard attributes. The ones a security reviewer cares about:

• session.id, Claude Code's own session identifier.
• organization.id, the organization UUID when the user is authenticated.
• user.account_uuid and user.account_id, tied to the Anthropic account.
• user.id, a random anonymous identifier stored in ~/.claude.json, not derived from the account.
• user.email, included when available from sign-in.
• terminal.type, for example a terminal emulator or an IDE.
• Repository identity attributes (vcs.repository.name and related keys), which are off by default and turned on with OTEL_METRICS_INCLUDE_REPOSITORY=true on recent versions.

Events also carry prompt.id, which ties a prompt to everything that followed it until the next prompt, and agent_id and parent_agent_id for sub-agent activity on recent versions.

The event list is long. The ones that answer audit questions are the user prompt event (length by default, not text), the tool decision event (whether a tool use was accepted or rejected and where the decision came from), the tool result event, the API request and API error events (model, tokens, cost, duration), the permission mode changed event, the MCP server connection event, the plugin and skill events, the hook events and the managed settings resolved event. Anthropic's page also has a section on auditing security events, with a table that maps common security questions to the events that answer them. Read it before you design dashboards.

On privacy, Anthropic's page says export is opt-in, that raw file contents and code snippets are not included in metrics or events, that prompt content is not collected by default and only its length is recorded, and that user.email is sent only to the endpoint you configure, never to Anthropic. Four variables add content, all off by default:

There is a further option, OTEL_LOG_RAW_API_BODIES, that emits whole API request and response bodies, conversation history included. Anthropic's page says turning it on implies consent to everything the other content gates would reveal. Treat it as a debugging tool for a single machine, not a fleet setting.

Codex

OpenAI's advanced configuration page for Codex describes OpenTelemetry log export that is off by default and switched on through the [otel] table in config.toml. The exporter defaults to none; you set it to otlp-http or otlp-grpc to send events. With none, Codex records events but sends nothing. The page says exporters batch asynchronously and flush on shutdown.

The [otel] table takes an environment tag (it defaults to dev) and log_user_prompt, which redacts user prompts unless you turn it on. Event metadata includes the service name, CLI version, environment tag, conversation ID, model, and the sandbox and approval settings.

The representative event types OpenAI lists:

Two details matter for a security pipeline. First, codex.tool_decision tells you whether an approval was a human click or a standing rule, which is exactly the AU-3 "source of the event" question for agents. Second, codex.tool_result carries an output snippet. That is content, and it is not covered by log_user_prompt, so decide in advance what your receiver does with it.

Codex also has an OTel metrics pipeline with counters and duration histograms for API, stream and tool activity, tagged with auth_mode, originator, session_source, model and app.version. OpenAI's page notes that a metric's tool field names the internal tool, such as a shell or patch tool, and does not contain the actual shell command or patch. Separately, Codex sends a small amount of anonymous usage data to OpenAI by default; setting enabled = false under [analytics] turns that off, and OpenAI's page says it also disables custom OTLP metrics exporters in the Codex CLI. If you need Codex metrics in your own backend, check that interaction before you switch analytics off.

OTLP in one paragraph

OTLP is the OpenTelemetry Protocol. Over HTTP it sends protobuf or JSON payloads to three paths, /v1/traces, /v1/metrics and /v1/logs, with Content-Type set to application/x-protobuf or application/json. The OpenTelemetry exporter specification defines the environment variables both vendors build on: OTEL_EXPORTER_OTLP_ENDPOINT as a base URL to which the SDK appends the signal path, per-signal variables such as OTEL_EXPORTER_OTLP_LOGS_ENDPOINT used exactly as given, OTEL_EXPORTER_OTLP_HEADERS as comma-separated key and value pairs, and OTEL_EXPORTER_OTLP_PROTOCOL with the values grpc, http/protobuf and http/json. The base URL versus full URL distinction is the source of most first-day failures, and it is why Claude Code takes a base URL while the Codex example takes the full /v1/logs URL.

Step by step, with any OTLP receiver

These steps work whatever backend you send to: a self-hosted Collector, an observability platform, a SIEM with an OTLP front end, or Safeguard. Do them in order.

1. Write the logging policy first

Before any variable is set, write a half page that answers five questions. It is the "enterprise-approved event logging policy" the CISA guidance asks for, scoped to agents.

2. Pick the transport

Use OTLP over HTTP unless you control every hop. gRPC needs HTTP/2 from the exporter to the receiver; corporate proxies, some load balancers and many public edges speak HTTP/1.1. http/protobuf is the compact default; http/json is easier to debug by eye. Turn on gzip where the exporter supports it.

3. Create one credential per group

Issue a separate token for each fleet or team: engineering laptops, build agents, the data science group. One token per group lets you revoke a leaked credential without blinding the whole estate. The token should only be able to write telemetry; it must not read anything back. That is AU-9 in practice.

4. Configure Claude Code through managed settings

Anthropic documents a managed settings file that administrators deploy to every machine, and an env block inside it that sets environment variables for every session. Setting the OTLP variables there does three useful things, according to Anthropic's monitoring page:

• When managed settings set OTEL_EXPORTER_OTLP_ENDPOINT, Claude Code removes every developer-set per-signal endpoint at startup, so a developer cannot point one signal somewhere else.
• When managed settings set OTEL_EXPORTER_OTLP_HEADERS, Claude Code removes the developer-set per-signal headers and every developer-set endpoint, so the credential cannot reach a collector the administrator did not choose.
• The exporter selectors (OTEL_METRICS_EXPORTER, OTEL_LOGS_EXPORTER) follow normal precedence, so a developer can still switch a signal off unless you set the selectors in managed settings too.

Anthropic's page also says Claude Code ignores the exporter variables in a repository's .claude/settings.json and .claude/settings.local.json, so a repository cannot turn telemetry on, choose its destination or capture content. A repository can still set a signal's exporter to none unless managed settings or the launch environment set that variable. Set the selectors in managed settings and that loophole closes.

For per-team reporting, OTEL_RESOURCE_ATTRIBUTES adds your own keys, such as department or team.id, as comma-separated key=value pairs. Anthropic's page warns that values with spaces must be percent-encoded, and that custom keys never override the standard attributes such as user.id or session.id.

If you need short-lived credentials rather than a static header, Claude Code supports an otelHeadersHelper setting that points to a script which prints the headers as JSON. Anthropic's page documents its refresh behaviour and the warning shown when it fails.

Cloud sessions are a separate case. Anthropic's page says cloud sessions run in cloud environments, not on your users' devices, so a managed settings file on the laptop does not configure them. Server-managed settings do reach most of them, and Anthropic warns not to put a collector token in an environment's variables, because anyone who uses the environment can read them.

5. Configure Codex in config.toml

Codex reads ~/.codex/config.toml. Add an [otel] table, set log_user_prompt = false, give the deployment an environment tag, and configure otlp-http with the full logs URL, protocol = "binary" for protobuf, and the token in a header. OpenAI's example reads the header value from an environment variable with ${...} syntax, which keeps the secret out of the file. Push the file and the environment variable with whatever you already use for developer machine configuration.

6. Decide content handling at the receiver too

Do not rely only on the sender's settings. A developer can set OTEL_LOG_USER_PROMPTS=1 in a shell where managed settings do not pin it, and Codex tool results carry output snippets regardless. The receiver should drop or redact content by default, and redact credentials in every value it keeps. If you run your own Collector, Anthropic's page shows an attributes processor that deletes both prompt attributes (prompt and prompt_text), and notes that a masking rule must name both.

7. Verify on one machine before the fleet

Anthropic's page gives a clean check: with metrics on, look for the claude_code.session.count metric, which is emitted when a session starts; with only logs on, submit a prompt and look for the claude_code.user_prompt event. For Codex, run one task and look for codex.conversation_starts. Temporarily lowering the export interval helps while you test; reset it afterwards.

8. Write the first three detections

Collecting is AU-12. Reviewing is AU-6. Start with three rules you can explain to an auditor:

1. A tool decision that was approved by configuration rather than by a user, on a repository marked sensitive.
2. A connection to an MCP server that is not on your approved list.
3. A change of permission mode to the least restrictive setting.

Tune them for a week before anyone is paged.

A one-page rollout checklist

Should you log prompts and tool content?

Default to no. The privacy notes on both vendors' pages make the same point: the default records the shape of the activity (lengths, decisions, durations, tokens) and leaves the words out. That is enough to answer who ran what, when, with which approval, and what it cost.

Content becomes useful in narrow cases: investigating a specific incident, studying prompt injection attempts against an internal tool, or proving that a particular instruction was given. In those cases, turn content on for a named group, for a fixed period, with a receiver that redacts credentials and truncates long values, and with retention no longer than the investigation needs. Write the exception down. If content is on everywhere "just in case", the log store holds the most sensitive text in the company and becomes a target in its own right. The same reasoning applies to MCP servers; see MCP server telemetry and data governance.

Metrics, logs or traces: which do you need?

For security and audit, events (logs) carry the answers: the tool decision, the tool result, the MCP connection, the permission change. Metrics answer cost and adoption questions: sessions, tokens, cost by team and model. Traces show the full shape of one session as a tree of spans and are mainly useful when you are debugging a specific workflow.

Start with logs and metrics from Claude Code, and logs from Codex. Add traces only when a question needs them, and remember that span attributes have their own content gates in Anthropic's docs.

One schema detail matters if you compare token use across tools. OpenTelemetry's semantic conventions for generative AI define gen_ai.* attributes, and Anthropic's page notes that Claude Code does not set the gen_ai.usage.* attributes. It reports input tokens as the API's usage block gives them, which excludes prompt cache reads and writes, while the GenAI conventions count cache tokens inside input tokens. Add the cache figures before you put Claude Code numbers next to anything instrumented with the GenAI conventions.

Collector in the middle, or send direct?

Sending directly from each tool is the shortest path and is fine for a few hundred machines. If you already ship security telemetry to an observability platform, our guide to sending security telemetry to observability platforms covers the general pattern. Put an OpenTelemetry Collector in the middle when you need any of these: batching for a large fleet, a second destination such as your existing observability platform, an extra redaction stage you control, or a single egress point that your network team can allowlist.

The Collector's OTLP over HTTP exporter takes an endpoint, an encoding (proto or json), compression and headers. The Collector project's README now names it otlp_http and keeps otlphttp as a deprecated alias that will be removed in a future version, so use the new name in new configuration. Gzip compression is on by default. The cost of the Collector is one more service to run and patch, and one more place a token lives.

How Safeguard does this

Safeguard's OpenTelemetry (OTLP) integration (GA) is the receiver end of everything above. The docs page describes it as receiving OpenTelemetry logs, metrics and traces over OTLP/HTTP from your own exporters: Claude Code, OpenAI Codex, or any OpenTelemetry Collector. It is switched on per workspace; if the card is not visible under Integrations, the docs say to ask your Safeguard contact.

What happens to the data, per the docs: telemetry from Claude Code and Codex becomes AI agent events, AI Detection and Response (AIDR) detections in Detection and Response (GA), and events in Security Operations (GA). Telemetry from other sources is kept as generic telemetry when the token's policy allows it. Safeguard never connects to Claude, Codex or OpenAI for this integration; it reads only what your exporters send with your token, and the docs state that no customer data from this integration is sent to third-party LLMs.

The steps below follow the docs page exactly. I have not run these snippets against a live workspace for this post; they are copied from docs.safeguard.sh as published on 25 October 2026.

1. Issue an ingest token

1. Open Integrations, choose the Project/Product tab and click the OpenTelemetry (OTLP) card.
2. Under Issue an ingest token, enter a Name (for example "Engineering laptops") and click Issue token.
3. Copy the token. The docs say Safeguard shows it only once and stores only its hash; if it is lost, rotate it.

The token starts with sg_otlp_. It only lets an exporter send telemetry to your workspace and cannot read anything back. Safeguard API keys, sign-in tokens and vendor API keys are refused by the receiver. Issuing, rotating and revoking tokens needs a workspace admin; workspace members can view the token list and what has been received.

Each token carries a policy with three switches:

The docs' least privilege advice is one token per group of machines, content kept off, and retention as short as your policy allows, 30 days by default.

2. Point Claude Code at the endpoint

The endpoint base is https://api.safeguard.sh/gpt/api/v1/otlp. Claude Code appends the signal paths itself. For one machine, the docs show these variables in the shell profile or the env block of Claude Code's settings:

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=otlp
export OTEL_LOGS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
export OTEL_EXPORTER_OTLP_ENDPOINT=https://api.safeguard.sh/gpt/api/v1/otlp
export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer sg_otlp_YOUR_TOKEN"

For every machine, the docs put the same values in the env block of Claude Code's managed settings:

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "http/protobuf",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "https://api.safeguard.sh/gpt/api/v1/otlp",
    "OTEL_EXPORTER_OTLP_HEADERS": "Authorization=Bearer sg_otlp_YOUR_TOKEN"
  }
}

Because the endpoint and headers come from managed settings, Anthropic's precedence rules described earlier apply: developer-set endpoints and per-signal headers are removed at startup. The docs tell you to leave OTEL_LOG_USER_PROMPTS, OTEL_LOG_TOOL_DETAILS, OTEL_LOG_ASSISTANT_RESPONSES and OTEL_LOG_TOOL_CONTENT unset unless your policy allows content, and add that even when they are set, Safeguard drops that content unless the token's Keep content policy is on. That gives you the receiver-side backstop from step 6 of the generic walkthrough.

3. Point Codex at the endpoint

Codex sends its events as logs, so the docs use the full logs URL. Add this to ~/.codex/config.toml:

[otel]
environment = "prod"
log_user_prompt = false

[otel.exporter.otlp-http]
endpoint = "https://api.safeguard.sh/gpt/api/v1/otlp/v1/logs"
protocol = "binary"

[otel.exporter.otlp-http.headers]
"x-safeguard-ingest-token" = "${SAFEGUARD_OTLP_TOKEN}"

Then set SAFEGUARD_OTLP_TOKEN to your token in the environment Codex runs in. This uses the second supported header, x-safeguard-ingest-token, which carries the same token for exporters that already use Authorization for something else. The table form is the same TOML as the inline form in OpenAI's own example.

4. Or send through an OpenTelemetry Collector

If you run a Collector, the docs add an otlp_http exporter and list it in each pipeline:

exporters:
  otlp_http/safeguard:
    endpoint: https://api.safeguard.sh/gpt/api/v1/otlp
    encoding: proto
    compression: gzip
    headers:
      Authorization: "Bearer ${env:SAFEGUARD_OTLP_TOKEN}"

service:
  pipelines:
    logs:
      exporters: [otlp_http/safeguard]
    metrics:
      exporters: [otlp_http/safeguard]
    traces:
      exporters: [otlp_http/safeguard]

Your receivers and processors stay as they are; this adds a destination. The docs note the exporter was named otlphttp before Collector 0.161 and the old name still works.

5. Confirm data is arriving

Back on the OpenTelemetry (OTLP) card, the Set up an exporter tabs (Claude Code, Codex, OTel Collector) show the same snippets with the token you just issued filled in. Start the exporter. Under Received, the Log records, Data points and Spans counters count up within a minute, given Claude Code's default export intervals.

6. Review what was stored

The docs list what Safeguard keeps: AI agent events (session, tool decisions and results, model calls, tokens and cost, sub-agent links), AIDR detections in Detection and Response, Security Operations events, and, when Keep other telemetry is on, generic telemetry with its attributes cut to an allowlist. Everything is kept for the token's retention.

Two protections apply on arrival whatever the token policy says. Credentials in every kept value are redacted, including API keys for common providers, private keys, bearer tokens, passwords in key=value pairs and credentials in URLs; each becomes a REDACTED marker naming its kind. Prompt, tool input, response and message content is not stored, only its length, unless Keep content is on; and even then it is redacted, truncated and stored but never searchable.

7. Rotate and disconnect

To rotate, click Rotate in the token list, set a Grace period (minutes) if exporters need time to pick up the new value, and copy the new token into every exporter. The old token stops working when the grace period ends. To disconnect, click Revoke; exporters using that token are refused from then on, and data already received stays until its retention ends. Then remove the OTLP settings from Claude Code, Codex or the Collector. The docs say ingest tokens do not expire on their own and suggest rotating them on your normal credential schedule, and whenever a machine image or configuration holding one leaves your control.

Where this fits with the rest of Safeguard

Telemetry tells you what happened. Other Safeguard controls act in the path or in the pipeline:

The gates do not read OTLP telemetry; they evaluate the code and dependencies in a change, wherever it came from. Pairing them is the point: the telemetry shows the agent installed a package, and the gate decides whether that package ships.

Troubleshooting from the docs

Size and rate limits apply per request, per token and per workspace; over a limit, Safeguard answers 413 or 429 with Retry-After, and OTLP exporters retry on their own. The docs page lists the exact limits.

What Safeguard does not do

• It does not turn telemetry on for you. Safeguard receives what your exporters send. Deploying managed settings to Claude Code and config.toml to Codex machines stays your job, with your endpoint management tooling.
• It does not call Anthropic or OpenAI for this integration. Anything that never leaves the machine as telemetry is not in Safeguard. If a developer runs an agent with telemetry off, or a tool Safeguard does not map, you see no AI agent events for it.
• It does not accept OTLP over gRPC. The docs say gRPC needs HTTP/2 end to end and the public edge answers HTTP/1.1. Exporters must use http/protobuf or http/json.
• It does not keep content by default. With Keep content off, you get lengths, not text. If an investigation needs prompt text, someone has to turn content on at both the sender and the token, ahead of time.
• It does not prevent an agent action. Telemetry is after the fact. Blocking a tool call or a model request is the job of MCP Guardrail, AI Gateway or the agent's own permission settings.
• It does not judge intent. AIDR detections flag patterns; a person still decides whether a session was misuse, a mistake or normal work.
• It does not replace your retention decision. The default retention is a starting point. If your policy or regulator needs longer or shorter, set it on purpose.
• It is switched on per workspace. If the card is missing, the integration is not yet on for that workspace.

Common mistakes

• Pointing Codex at the base URL. Codex's example takes a full logs URL. Without /v1/logs, the receiver answers "Unknown signal".
• Setting the protocol to gRPC out of habit. grpc is a valid OTLP protocol, and OpenAI's own Codex page shows an otlp-grpc exporter on port 4317. Against an HTTP-only receiver it fails, and the error mentions Content-Type, not the protocol.
• Putting the token in a repository. A token in a committed .claude/settings.json does not even work, since Claude Code ignores exporter variables there, and it leaks a credential. Use managed settings or the environment.
• Leaving exporter selectors to developers. If only the endpoint is in managed settings, a developer can still set OTEL_LOGS_EXPORTER=none. Pin the selectors too.
• Turning on content for debugging and forgetting it. Set an end date on every content exception.
• One token for everything. A single shared token means one leak blinds the whole fleet when you revoke it.
• Forgetting cloud sessions. Laptop managed settings do not reach agents running in cloud environments. Check where your agents actually run.
• Switching off Codex analytics without checking metrics. OpenAI's page says disabling analytics also disables custom OTLP metrics exporters in the Codex CLI.
• Treating collection as review. AU-6 needs someone or something to read the events. Write the first detections in week one.

FAQ

Does Claude Code send telemetry by default?

Not to your systems. Anthropic's docs say OpenTelemetry export is opt-in and needs explicit configuration, starting with CLAUDE_CODE_ENABLE_TELEMETRY=1. Anthropic's separate operational telemetry is covered on its data usage page.

Does Codex support OpenTelemetry?

Yes. OpenAI's Codex docs describe OTel log export, off by default, configured in the [otel] table of config.toml with an otlp-http or otlp-grpc exporter. Codex also has an OTel metrics pipeline.

Are prompts included in Claude Code telemetry?

Not by default. Only prompt length is recorded. OTEL_LOG_USER_PROMPTS=1 adds prompt text, and Anthropic's page lists other gates for responses, tool details and tool content.

What endpoint path do I use for Claude Code versus Codex?

Claude Code takes a base URL in OTEL_EXPORTER_OTLP_ENDPOINT and appends /v1/logs and /v1/metrics itself. The Codex example takes the full /v1/logs URL. For Safeguard, that is the base https://api.safeguard.sh/gpt/api/v1/otlp for Claude Code and the same base plus /v1/logs for Codex.

Can developers turn Claude Code telemetry off or redirect it?

If you set the endpoint and headers in managed settings, Anthropic's docs say Claude Code removes conflicting developer values at startup. Exporter selectors follow normal precedence, so pin them in managed settings as well if you need them locked.

Do I need my Anthropic or OpenAI API key to send telemetry to Safeguard?

No. The Safeguard docs say vendor API keys are never needed: your exporters send to Safeguard, and Safeguard does not call the vendor. The receiver accepts only a Safeguard ingest token.

Why does Safeguard only accept OTLP over HTTP?

The docs say gRPC needs HTTP/2 end to end and Safeguard's public edge answers HTTP/1.1. Use http/protobuf or http/json, with gzip if you like.

What happens to API keys that appear in telemetry?

Safeguard's docs say credentials in every kept value are redacted on arrival, including common API keys, private keys, bearer tokens, passwords in key=value pairs and credentials in URLs.

Can I send telemetry from other tools too?

Yes, through any OpenTelemetry Collector. Telemetry that Safeguard does not map to AI agent events is stored as generic telemetry when the token's Keep other telemetry policy is on, with attributes cut to an allowlist.

How do I rotate an ingest token without losing data?

Click Rotate in the token list, set a grace period so the old token keeps working while you update exporters, and copy the new token everywhere before the grace period ends.

Fixing what the agents touch

Telemetry tells you which packages an agent pulled in and which files it changed; it does not fix the vulnerable dependency it chose. The section below is how Safeguard closes that gap once you know where it is.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo shows Claude connected to the Safeguard MCP server with OAuth, and how you choose which tools Claude can use. It is the other half of agent governance from this post: telemetry records what a Claude Code session did, and the tool selection decides what it may do with Safeguard in the first place.

Click through it at your own pace, or open it full screen.

The second demo is a real desktop app session: the CLI session shows in the conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit, and it ends with the upgrade done and tests passing. Those per-step approvals are the same kind of record that the tool decision events in this post capture for Claude Code and Codex.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Safeguard docs: OpenTelemetry (OTLP) integration
• Safeguard docs: Integrations
• Safeguard docs: ESSCM integrations
• Safeguard docs: Claude (Anthropic) integration
• Safeguard docs: OpenAI API Platform integration
• Claude Code docs: Monitoring
• Claude Code docs: Settings
• OpenAI Codex docs: Advanced configuration
• OpenAI Codex docs: Configuration reference
• OpenTelemetry: OTLP specification
• OpenTelemetry: OTLP exporter configuration
• OpenTelemetry Collector: OTLP/HTTP exporter README
• OpenTelemetry: Semantic conventions for generative AI
• NIST SP 800-53 Rev. 5 catalog (OSCAL)
• CISA: Best Practices for Event Logging and Threat Detection
• OWASP GenAI: LLM06:2025 Excessive Agency
• OWASP GenAI: LLM02:2025 Sensitive Information Disclosure
• OWASP GenAI: LLM01:2025 Prompt Injection
• Safeguard docs: AI agent discovery
• Safeguard docs: SecOps (SIEM)

Download Safeguard at safeguard.sh/download, and read the product documentation at docs.safeguard.sh.

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.