fix(codex): attribute MCP calls emitted as event_msg/mcp_tool_call_end (#478)#513
Merged
Conversation
Recent Codex sessions report completed MCP tool calls as an event_msg with type mcp_tool_call_end instead of a function_call response_item. The parser only built its tool list from function_call and patch_apply_end events, so these MCP calls were never attributed: token usage was still counted, but the MCP tool itself was missing from recent lookback windows (today/week/month) while older history still showed it. Add a handler that reads invocation.server and invocation.tool from the event and rebuilds the canonical mcp__<server>__<tool> name the classifier recognizes. Bump the Codex result cache to v4 so sessions cached under v3 re-parse and pick up the previously dropped MCP calls. Validated on real local data: 5 mcp_tool_call_end events that were dropped before are now attributed as mcp__node_repl__js, with no change to the total call count. Fixes #478
This was referenced Jun 18, 2026
iamtoruk
added a commit
that referenced
this pull request
Jun 18, 2026
The export schema emitted tools and shell-commands but no MCP section, and the tools list is built from extractCoreTools which strips mcp__ names, so MCP usage never appeared in codeburn export output even when sessions had MCP activity (issue #496). Add an mcp section to the JSON export and an mcp.csv to the CSV export, sourced from session.mcpBreakdown (server -> calls, with share). Mirrors the existing tools section. The underlying parse fix (Codex mcp_tool_call_end attribution) landed in #513; this makes that data visible in exports. Validated on real local data: the JSON export now reports mcp: [{Server: node_repl, Calls: 5, ...}]. Fixes #496
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Codex MCP usage shows up in long lookback windows but not in recent ones (
today,week,month). Reported in #478.Recent Codex sessions report a completed MCP tool call as an
event_msgwithtype: "mcp_tool_call_end"instead of afunction_callresponse_item. The provider only built its tool list (pendingTools) fromfunction_callandpatch_apply_endevents, and MCP is recognized purely by themcp__<server>__<tool>naming convention reaching that list (classifier.ts:45,parser.ts:965). So these calls were never attributed: token usage was still counted, but the MCP tool itself was dropped. Older sessions emitted MCP asfunction_callitems carrying themcp__prefix, which is why long windows still showed it.Fix
event_msg/mcp_tool_call_endthat readsinvocation.serverandinvocation.tooland rebuilds the canonicalmcp__<server>__<tool>name. Verified against the Codex source event shape (McpToolCallEndEvent->{ type, call_id, invocation: { server, tool, arguments }, ... }). Uses_endso each call is counted once after it completes; empty server/tool are skipped so a malformed event can't produce an invalid name.Validation on real local data
mcp__node_repl__jsx5Matches ground truth: the raw JSONL holds exactly 5 genuine
mcp_tool_call_endevents across two recent sessions, all dropped before and all attributed after. Total call count unchanged (no double-counting; token totals untouched).New test
attributes MCP calls emitted as event_msg/mcp_tool_call_endasserts the reconstructed name. Full codex suite 18/18,tsc --noEmitclean.Fixes #478