Epic: Bring Codex to parity with Claude Code — cost, sessions, tool pruning, and the unverified surface

This is a tracking epic, not a single task, and it depends on the unmerged PR #1337. A reasonable entry point is the tool-prune and inference-parser suffix lists, which should share one predicate; check that the /responses path is recognised in both. The other sections need design decisions first, such as whether to bundle non-Anthropic prices, so start by asking a maintainer which section to take.

Follow-on to #942, which lands Codex as a recognised, configurable, parsed agent — the same tier as OpenCode. This issue tracks what it still lacks relative to Claude Code, the reference integration, plus everything #942 shipped unverified.

Depends on #1337 (the PR that completes #942). Nothing here is a regression; it is the gap between "supported" and "at parity".

Where Codex stands today

Capability	Claude Code	OpenCode	Codex
Recognised agent / per-agent metrics	✅	✅	✅ (#1337)
Persistent configure + revert	✅	✅	✅ (#1337)
Typed inference events	✅	✅	✅ (#1315, #1326)
Token counts	✅	✅	✅
Cost	✅	model-dependent	❌
Named sessions	✅	✅	❌
Tool pruning	✅	❌	❌

---

1. Cost — and this is NOT Codex-specific

Worth stating first because it reframes the work: the bundled price table is Anthropic-only by design. Its generated header says so — "VENDOR LIST prices for the first-party Anthropic endpoint" — and every one of its ~33 entries is a claude-* model. There are zero OpenAI rates.

So Codex's blank cost is not an integration gap. Measured on a live turn: gpt-6-luna reports 1 priceable request and 0 priced ones, with no amount — exactly the "find traffic that is not priced" signal working as designed. OpenCode pointed at a GPT model would report the same.

Two things to decide, and only the second is Codex's:

• Should Cortex bundle non-Anthropic rates at all? A cross-cutting decision affecting OpenCode and any gateway deployment, not just Codex. The generator already reads LiteLLM's full table, so the data is available; the question is whether shipping other vendors' list prices is in scope.
• Document the pricing: override path in docs/agents/codex.md. Cheap, in scope today, and the right answer regardless of the above. Note the wrinkle: Codex's model is served on a ChatGPT subscription, not per-token billing, so any per-token rate an operator sets is an imputed cost rather than a real one. The doc should say that rather than implying a missing number.

2. Named sessions

Codex's traffic lands in a pending:codex@<pid>.<start> bucket and never leaves it, because it sends none of the three session headers a laptop install reads (X-Claude-Code-Session-Id, X-Task-Id, X-Session-Id). Every other supported agent supplies one: Claude Code, Bob Shell (BobSessionHeader) and OpenCode (SessionIDHeader) each have their own.

Evidence that none arrives: the bucket is never adopted, and adoption only requires any one of the three to carry a value.

• Capture Codex's full request headers and establish whether it sends any stable conversation/thread id. Codex has a session concept of its own (codex resume, ~/.codex/sessions/, session_index.jsonl), so an id may exist on the wire under a name Cortex does not read. If it does, adding it to session.id_headers may be the whole fix.
• If no header exists, decide between: deriving a session from Codex's own rollout/session files (agentop already harvests Claude Code transcripts, so there is precedent), improving process-tree attribution, or accepting per-process buckets and documenting it.

3. Tool pruning

Unsupported for three independent reasons, any one sufficient — all confirmed by reading the code:

• agentop tools scan discovers tools from Claude Code's transcripts (~/.claude/projects/*.jsonl) and proposes only Claude Code's 26 hardcoded built-in names (cmd/agentop/toolscan/known.go). Nothing builds a Codex list.
• tool-prune's default paths are /v1/chat/completions, /v1/completions, /v1/messages. /responses is absent, so it records skip / path_not_inference on every Codex inference request.
• Even with paths overridden, it reads the manifest from a top-level tools array, while Codex nests its manifest under input[].tools[].tools[]. It would skip with no_tool_manifest.

Also worth fixing while in here, and arguably first:

• tool-prune and inference-parser keep separate suffix lists, and only the parser's recognises /responses. The drift is silent — the parser parses a request the pruner calls "not inference". One shared predicate would stop the next dialect hitting this.

OpenCode is also unsupported here, so this is the one row where Codex matches OpenCode and only Claude Code is ahead.

4. Unverified surface from #942

Everything #942 shipped was tested on Codex 0.160.1, macOS 26.3 (arm64), against the ChatGPT backend. Untested:

• Linux, and any other Codex version. Every User-Agent string, the CODEX_ dotenv filter and the .env load behaviour are pinned to that one build.
• A live TUI capture. Done — captured in #1337 by allocating a pty directly and typing into the real TUI. Both tokens confirmed, including codex-tui on the TUI's own /backend-api/codex/responses inference requests. The capture also caught an auto-update, so it covers 0.160.1 and 0.162.1, which is the only evidence that the UA shape holds across releases. It corrected one detail: the third UA field is the TERM value, not a literal unknown.
• The five unclaimed originator tokens: codex_vscode, codex_desktop, codex-app-server, codex_mcp_server, codex-cli. All present in the binary; none seen on traffic or traced to a client_name. Deliberately not folded into codex (a wrong fold is silent where an unrecognised agent is not) — but codex_vscode and codex_desktop plausibly belong to separate products, the way IBM Bob the IDE does to Bob Shell, and each needs its own decision.
• The public /v1/responses API with an OpenAI API key rather than a ChatGPT subscription. The parser recognises the path, and its non-streaming shape is modelled from the published schema rather than captured traffic.
• A function_call-shaped tool call. Codex's own exec tool is a custom_tool_call; the function_call branch is modelled from the documented schema and has never run on real traffic.
• The cost path, unexercised for Codex because no rate applies (see §1).

5. Smaller known issues

• CODEX_HOME must be set where agentop runs, not only where Codex runs — agentop reads it from its own environment. If Codex is launched with it set (wrapper script, devcontainer, launchd unit) and agentop configure codex enable is run from a plain shell, the two resolve different files and status confirms the wrong one. Documented with --env as the workaround; nothing outside can detect the split.
• Chatty non-inference traffic. One codex exec turn produced ~100 recorded events, most of them plugin-list polling and an MCP handshake rather than inference. Consider whether any belong in listener.skip_hosts guidance for Codex users.
• InferenceToolCall.Arguments is not JSON for Codex. custom_tool_call arguments are freeform text by design. sparc's reflector tolerates it (JSONDecodeError fallback); opa hands it to Rego as a plain string, so a policy calling json.unmarshal on it is the policy author's problem. Documented, but worth a guardrail or a worked Rego example.

Related

• #942 — lands Codex as a supported agent (this issue's prerequisite)
• #1337 — the PR completing #942
• #1363 — Claude Code's second User-Agent is unrecognised; same bug class as #1337's TUI blocker
• #1289 — the Prior/Written revert gap, shared by all the configure integrations

Assisted-By: Claude (Anthropic AI) [email protected]