Codex expanded a Windows-only release into cross-platform work, logged 460M tokens, and misreported total usage #59236

Incident summary

I asked Codex Desktop on Windows to finish a bounded Townlight beta: migrate package names, complete Access and Notice, verify the exact signed Windows MSI in a fresh Windows Sandbox, and push and merge ready source changes. I reserved tagging and publication for my approval. The approved plan explicitly called for a single Windows candidate.

Codex turned Linux CI failures into a Windows release gate before checking whether GitHub required that job for merge. It spent time fixing Linux archive lifecycle failures, characterized cross-platform work as necessary to finish Windows, and later admitted that the plan contained no Linux or macOS release requirement. I had to explicitly stop Linux and macOS work and then stop the entire effort. The refreshed Windows beta was still incomplete.

What happened

1. An earlier signed MSI from source 706028a passed Windows Sandbox acceptance, including Access, Notice, Meetings, and the Station-to-Records handoff.
2. Codex moved to refreshed suite source 51866f7. It tried to reuse the earlier executable before discovering that two changed manifests were compiled into it. That packaging attempt was canceled and the executable rebuilt.
3. Suite PR feat: adding ascii art banner #297 touched paths covered by the existing installer-cleanroom workflow. The workflow automatically ran Windows, Linux, and macOS readiness checks and a Linux archive lifecycle. Codex treated the failing Linux job as a release prerequisite without first verifying the applicable branch rules. It worked through stale package-version expectations and then a Linux repair failure.
4. Linux repair exposed a shared Core catalog fingerprint defect involving row collation. Codex described it as blocking Windows before reproducing it on Windows. A focused fix was opened, but the refreshed Windows MSI remained unsigned and unverified when I stopped the work. Codex did not put the already-signed Windows candidate forward as a route to finish until I challenged the amount of release work.
5. When I asked how much time and usage it had spent, Codex gave me 1,711,018 tokens and 2h 33m 55s from the paused goal counter and presented that as the total. I challenged the answer because the work had spanned multiple calendar days. A subsequent audit of local session records found 460,308,416 logged OpenAI tokens across the main thread and its linked sessions before the audit.

Measured impact

The recorded work spans 26 hours and 38 minutes of wall-clock time, from November 2 at 11:44 a.m. to November 3 at 2:22 p.m. Mountain time. The refreshed signed Windows beta was not delivered. The available records do not provide a defensible Linux/macOS-only time or token subtotal.

The total contains 450,958,720 cached input tokens, 8,413,809 uncached input tokens, and 935,887 output tokens. Output includes 246,409 reasoning tokens. This is observed usage, with no verified dollar charge. Even after excluding cached input, the total is 9,349,696 tokens.

DeepSeek accounting is unresolved. All 23 attributable Codex sessions identified OpenAI as their provider. Host Ollama logs showed requests and DeepSeek model lookups during the same window, but the available records lacked the thread attribution and token counts needed to connect those calls to the incident. The audit verified zero attributable DeepSeek tokens. The actual DeepSeek total is unknown. Separate Townlight threads are excluded from the OpenAI total where their usage could not be attributed to this task. A rough estimate, though, looks like another quarter of a billion tokens on an API plan, during primetime.

Evidence

• Suite PR #297
• Installer-cleanroom workflow on the integration base commit
• Hosted archive run showing the Linux failures and macOS readiness checks
• Core catalog fix PR #79
• Usage was calculated from cumulative token events in the local Codex rollout records, taking deltas for the daily split and counting linked subagent and approval-review sessions separately. A per-session ledger is available locally.

What OpenAI needs to address

• Enforce the agreed delivery scope. A triggered CI workflow must not become a release requirement without evidence that it is required by the repository or explicitly requested by the user. Require Codex to identify that evidence before it starts out-of-scope remediation.
• Expose total usage before it gets this large. Show live thread and goal usage, including linked agents and approval reviewers. Separate cached input, uncached input, output, and billable units where available. Make user-set limits enforceable and surface overruns promptly.
• Make goal counters impossible to mistake for thread totals. Explain the counter's time window and which sessions and token categories it covers. Provide exportable per-session, per-model, and per-provider totals. Make external-provider activity traceable to the originating task when Codex invokes it.
• Investigate the context and review overhead. This task logged over 404 million tokens in the main thread and over 52 million more in automatic approval reviews. Explain what generated that volume and identify the safeguards that should have prevented it.
• Make stop verifiable. When the user stops work, show the terminal state of owned local jobs and the disposition of dispatched remote jobs, including any that remain active or cannot be canceled.