Codex App build 5175 rapidly exhausts 5-hour quota with subagent history replay and thread-list polling storm #32591

What version of the Codex App are you using (From “About Codex” dialog)?

Regression observed on 26.707.51957 (build 5175). Rolling back to 26.707.41301 (build 5103) removed the specific polling/replay behavior described below.

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 25.4.0 arm64 arm

What issue are you seeing?

After updating the macOS Codex/ChatGPT desktop app from build 5103 to build 5175, the 5-hour usage allowance was exhausted in a matter of minutes while several existing autonomous threads and their subagents were active.

During the peak incident, the displayed 5-hour allowance fell from approximately 76% remaining to approximately 4% remaining in under 10 minutes. The broader incident completed most of the 5-hour allowance in less than 30 minutes. The weekly allowance also fell by roughly 9 percentage points during the peak.

This was not only a display glitch: server-provided rate-limit percentages were decreasing. However, build 5175 also produced local accounting and lifecycle symptoms that made the apparent token totals much larger and harder to interpret:

1. thread/list polling storm

   • The desktop log recorded 1,570 thread/list requests in approximately 26 minutes.
   • Requests arrived in bursts, sometimes close to a 60 Hz cadence.
   • This occurred while navigating/resuming active threads.

2. Subagent rollout history replay

   • When some child agents were created, their new rollout files immediately received approximately 1,000-3,500 historical token_count and conversation events.
   • Thousands of records were written within the first second after child creation, which cannot represent fresh model calls.
   • The replayed records received new timestamps and appeared in multiple child rollouts, inflating naive local token totals into the billions.

3. High internal-call amplification remained after excluding replay

   • A sanitized local estimate that discarded the first two seconds of each child rollout and deduplicated identical usage tuples still found approximately 600 usage records and 67 million aggregate tokens across six concurrently active root threads during the 30-minute window.
   • Approximately 96% of those tokens were cached input.
   • These figures are diagnostic estimates, not a claim that every record was independently billed.

4. Cancellation did not immediately quiet child events

   • Cancelling the active tasks interrupted 11 root/child turns.
   • The desktop continued receiving item/hook events for conversations it reported as unknown for roughly 30 seconds, until the app exited.

5. Single-thread controlled observation on build 5175

   • After cancelling every other task, only one visible thread remained active.
   • One tool-heavy diagnostic question produced 18 internal model cycles and approximately 2.6 million aggregate tokens, mostly cached input, with context growing from roughly 116k to 177k tokens.
   • The 5-hour meter moved by approximately one percentage point during that single investigation.

After rolling back to build 5103 while retaining the same local Codex state:

• only the intentionally active thread loaded;
• the first approximately 100 seconds produced 8 thread/list calls instead of a high-frequency storm;
• no spawn-time history replay was observed;
• no unknown-conversation lifecycle errors were observed;
• cancelled autonomous threads remained unloaded.

No raw logs, prompts, thread names, account identifiers, repository names, local paths, or session IDs are included here because they contain private data. Sanitized excerpts can be provided privately if maintainers need them.

What steps can reproduce the bug?

1. On macOS arm64, install Codex App build 5103 and create several resumable/autonomous threads that can spawn subagents.
2. Update to build 5175 and relaunch the app.
3. Allow multiple existing autonomous threads to continue, including subagent creation, while switching among active thread views.
4. Monitor the 5-hour and weekly usage indicators.
5. Inspect the desktop log for high-frequency thread/list requests.
6. Inspect newly created child rollout files for large batches of historical token_count/conversation events written within the first second after creation.
7. Cancel all root and child turns and observe whether events continue arriving for unknown conversations.
8. Roll back to build 5103 with the same local state and repeat the observation.

The exact degree of quota depletion may depend on the number of active autonomous threads, selected models/reasoning levels, and accumulated context.

What is the expected behavior?

• Updating or relaunching the desktop app should not cause uncontrolled quota depletion from resumed autonomous work.
• thread/list should not poll at high frequency.
• Child rollouts should not replay historical usage records with new timestamps in a way that makes accounting appear newly generated.
• Cancelling a root task should reliably stop or close its active child turns.
• The usage UI should explain consumption from internal model cycles, cached input, subagents, retries, and autonomous continuation instead of presenting only an unexplained percentage.

Additional information

Possibly related, but not identical:

• GPT-5.6 Sol Medium depletes Pro 5-hour usage allowance extremely quickly #32250 - GPT-5.6 Sol rapidly depletes the Pro 5-hour allowance
• Codex Desktop consumed 80% of 5-hour usage limit within 5 minutes #28498 - Codex Desktop consumed 80% of a 5-hour limit within 5 minutes
• Codex usage page shows unstable remaining 5-hour quota #32410 - unstable remaining 5-hour quota in the app
• Issue with 5-Hour Usage Limit and Subagent Bug #29996 - subagent lifecycle behavior near quota exhaustion

This report adds a precise build regression and rollback comparison plus specific app-server polling, rollout replay, and cancellation-lifecycle evidence.