Monitor Codex tasks, tool calls, and token usage in Guance

Ask Codex to fix a bug, and the visible result may be a small diff. Getting there can involve reading files, making repeated model requests, running commands, and responding to test failures. The diff is ready for code review; the execution history needs a different kind of investigation.

When a task takes longer or consumes more tokens than expected, you need to know where the work accumulated. Was the model processing a large context? Did a command stall? Did the same failing test trigger several attempts? And if an operation was flagged as risky, what happened around it?

Guance Agent Monitoring lets you inspect the activity collected from Codex through sessions, traces, and spans. This guide explains how to use those views and how to verify collection with a task you can recognize. The setup is based on the current integration documentation, rather than a measured deployment in a customer environment.

Start with the task boundary

Without a session, a sequence of model requests and tool calls can look like unrelated events. Start at the session level to identify the coding task, review its input and output token totals, and locate any reported risk events. Where reported, check the session start and end times, interaction turns, trace count, and final status as well. From there, open the trace details to examine individual calls.

That sequence keeps the investigation tied to a specific piece of work. For example, a refactoring task may reasonably require more context than a small test change. Compare similar tasks before deciding that a large token total indicates a problem.

Token usage also needs to be distinguished from cost. Usage fields describe the data collected for the task. A monetary estimate depends on the relevant model, pricing, and billing arrangement; it should not be treated as the provider's final bill.

Follow slow or failed calls through the waterfall

The trace waterfall shows the timing and status of recorded steps. Open a span to inspect the available call details, then work outward to see what happened before and after it. A slow model request, a long-running command, and a failed test point to different next steps.

For a task that repeatedly runs the same test, look for the sequence of tool results and subsequent calls. A failure may explain the extra work, but the trace alone does not establish whether every retry was necessary. You still need to read the test result and inspect the resulting change.

Where the integration captures the relevant fields, tool-call details can help identify file access, command execution, tests, and Git operations. Treat these as recorded execution evidence. They do not expose the model's private reasoning, and a missing event does not prove that an operation never occurred. Collection settings and adapter behavior determine what you can see.

Investigate flagged operations in context

A command name by itself rarely tells the whole story. Reading a sample configuration in a test project has different implications from reading a file that holds production credentials. Use a risk event to locate the surrounding task and tool call, then inspect the information available for that operation.

Monitoring and enforcement have different roles. A risk event displayed in Guance is evidence for review; its presence does not by itself mean the operation was prevented. Check the relevant policy and collection coverage before relying on these events for a particular control.

The connector supports content-capture settings, including none, preview, and full, as well as a character limit. Those choices affect how much input and output is available for investigation. Select them deliberately for the repositories and environments you plan to monitor.

Keep the three integration paths distinct

Monitoring Codex is one use of Guance's Agent capabilities. Giving Codex access to operational data is another.

• Agent Monitoring collects information about Codex activity so that you can investigate its performance, token usage, failures, and reported risk events.
• MCP Server and OWL CLI provide ways for an authorized external Agent to query Guance data and use supported tools. Their purpose is to make observability data available during an investigation.
• Guance Agent Teams organizes observability Agents and operational workflows, including diagnosis and controlled actions in a production environment.

You can combine these paths, but one does not imply the others are configured. Collecting Codex telemetry does not automatically grant it access to your Guance workspace or authorize it to change production systems. See the product overviews for MCP Server, OWL CLI, and Guance Agent Teams (Chinese).

Connect Codex and verify a recognizable task

In the Guance console, go to Agent Monitoring > Summary, open the Agent tab, and select Integrate Agent. Choose Codex, review the user-identity option, and follow the installation instructions for your environment.

The documented integration uses obs-agent-connector. Its built-in Codex adapter uses a Stop Hook and handles the associated trust and configuration setup. Run obs-agent-connector agents to check support in the connector you are using, rather than assuming every installed version has the same capabilities. Use your workspace's endpoint and token when configuring collection.

After setup, run a small development task that reads a known file, executes a command, and runs a test. Then inspect the result in Guance:

1. Find the session associated with that task and confirm that its activity is grouped as expected.
2. Open the trace and look for the model and tool calls you know the task made.
3. Compare recorded durations, token fields, and statuses with the execution you observed.
4. If a test failed or an operation was flagged, check that the available details are sufficient to investigate it.

A visible session is a useful first check. The stronger test is whether you can explain a known delay or failure from the collected evidence. Establish that baseline before extending monitoring to more projects or using the totals for team-level reporting.

For installation and supported environments, use Create an Agent Monitoring Application and the connector command reference. The Agent Monitoring overview describes the session and trace views.