#Install the plugins

Install the Pydantic skills marketplace in Codex:

codex plugin marketplace add pydantic/skills

Then enable the Logfire and Logfire Exporter plugins in Codex. They do different jobs, so they have slightly different setup:

• Logfire Exporter needs a Logfire write token so it can send Codex turn and tool-call spans to your project.
• Logfire installs the Logfire MCP server so Codex can query records, generate trace links, and open Logfire UI views.

For the exporter, either set the token in the shell that launches Codex:

export LOGFIRE_TOKEN=...

or put it in the exporter config file:

~/.config/logfire-exporter/config.env

LOGFIRE_TOKEN=...
# Optional; defaults to https://logfire-api.pydantic.dev.
# LOGFIRE_BASE_URL=https://...

After enabling the exporter, restart Codex so the hook configuration is loaded. If Codex asks you to review the plugin hooks, run /hooks and approve them. The exporter listens to Codex lifecycle hooks, stores lightweight turn fragments locally during the turn, and exports the completed turn on the Stop hook. In other words, the first Logfire trace appears after a Codex turn finishes, not when Codex starts.

For the Logfire plugin, authenticate the MCP connection as you normally would for Logfire, using logfire auth or a suitable LOGFIRE_TOKEN. The plugin is configured for the US MCP endpoint by default; EU users can replace the MCP entry and re-authenticate:

codex mcp remove logfire
codex mcp add logfire --url https://logfire-eu.pydantic.dev/mcp
codex mcp login logfire
codex mcp get logfire

See the pydantic/skills repository for the full plugin READMEs and local-development setup.

:::note{title="Content capture"} By default, the exporter runs with CODEX_LOGFIRE_CONTENT_CAPTURE_MODE=full, which records redacted user prompts, assistant messages, tool inputs, tool outputs, and tool errors. Use no_tool_content to keep prompt and assistant content but omit tool input/output, or metadata_only to suppress prompt, assistant, and tool content entirely. Start with the default while testing locally, then choose the capture mode that matches your security policy before rolling it out to a team. :::

#The demo: one bug, two telemetry streams

For this post, we used pydantic/logfire-demo, a small distributed demo app with a FastAPI web UI, an arq worker, Postgres, pgvector, PydanticAI agents, and Logfire instrumentation already wired in.

The bug is real. In January 2026, the demo fixed a PydanticAI result API mismatch in PR #65: code that read response.data needed to read response.output.

For the recording, we did not check out old commits. We started from current main, created a dedicated branch, and reintroduced that one-line regression in the worker:

response = await ctx['ai_agent'].run(question)
logfire.info('Question: {question} Answer: {response}', question=question, response=response.data)

That gives us a stable current dependency set while still showing Codex investigate a genuine historical regression.

#Watch Codex work

The first half of the loop is agent observability. When the Logfire Exporter plugin is enabled, a Codex session becomes trace data.

In Logfire, a single Codex turn can include spans for:

• The submitted user prompt.
• Shell commands and other tool calls.
• Tool results, depending on content capture mode.
• Session lifecycle events.

That matters when an agent produces a surprising patch. You can inspect what it searched, which commands failed, which files it read, and what the final answer was grounded in.

Code review tells you whether the patch is right. This tells you how the agent got there -- the audit trail around the work.

#Let Codex query the app

The second half of the loop is application debugging. Codex should not need you to copy an exception from a dashboard into the chat. It should be able to ask Logfire directly.

For the demo, the prompt is intentionally plain:

The LLM Query worker started failing after the last change.
Find the most recent exception and tell me which file to fix.

What's useful here is that Codex earns the answer rather than recalling it. It queries the telemetry, finds the exception, connects it to the worker code, and points to the file that contains the bad result access.

The same investigation can be expressed as SQL when you want to inspect the underlying telemetry yourself:

SELECT
  start_timestamp,
  trace_id,
  service_name,
  span_name,
  exception_type,
  exception_message
FROM records
WHERE is_exception = true
  AND service_name = 'worker'
ORDER BY start_timestamp DESC
LIMIT 20

The exact query is less important than the shape of the workflow:

1. Start from a symptom.
2. Ask Logfire for the most recent relevant failure.
3. Follow the trace to the file and line.
4. Patch the code.
5. Verify the error disappears.

This is the same debugging loop you would run manually, but with less copy-paste and fewer guesses.

#Open Logfire inside Codex

Sometimes you want analysis, but sometimes, you would rather explore what's going on in the UI of Logfire. The Logfire plugin separates those routes. If you ask Codex to investigate an error, it should query telemetry and summarize what it found. If you ask it to open certain records in Logfire, it should open the right view in the Codex in-app browser.

For example:

Open the Logfire live view for errors in this project over the last hour.

Then, after the page is open:

Narrow it to the worker service only.

The second prompt updates the browser view instead of starting a separate investigation. That matters during a debugging session because the UI stays in the same workspace as the code and the agent chat.

Use this split as a rule of thumb:

#Why this works

There is no bespoke integration between Codex and Logfire. Two independent layers happen to meet on the same telemetry:

• OpenTelemetry defines the wire format and the GenAI semantic conventions, so a Codex session, a FastAPI request, and a PydanticAI agent call all describe themselves the same way.
• Logfire ingests that data and stores it as queryable records, whether it came from your application or from the Codex session itself.

Because the agent's work and the app's behavior land in the same project as the same kind of spans, Codex can query the substrate it runs on. The investigation and the thing being investigated share one table. That is what makes the loop close, rather than the two halves merely touching at the ends.

#Which plugin should you enable?

The two plugins are useful separately, but they are strongest together.

If you already use Logfire for your application, the Codex integration is a natural next step. Your app traces, your agent investigation, and the UI view can all live in the same project.

#What to try next

Install the Pydantic Codex plugins from pydantic/skills, enable Logfire Exporter for a local Codex session, and run one real debugging task with Logfire connected.

You do not need to turn your whole workflow over to an agent. Start with one incident. Let Codex find the trace, read the relevant file, and propose the fix. Then review it like any other patch.

That is the point: not magic debugging, just better plumbing between the code, the telemetry, and the tool doing the work.