Codex Security scan exhausted a freshly reset weekly allowance in ~44 minutes through worker/subagent fan-out

Start by tracing the Standard discovery-worker orchestration, including the subagents setting, and the rate-limit telemetry around usage_limit_exceeded. Compare worker creation near 95–100% usage with the reported 6%-versus-69% status; done should include bounded fan-out or task budgeting, stopping at exhaustion, and accurate current usage reporting.

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

26.911.61220

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Windows 11 x64 Build 26200

What issue are you seeing?

A single requested Codex Security assessment expanded into a large worker/subagent tree and consumed an entire freshly reset weekly Work/Codex allowance in approximately 44 minutes.

Local Codex rollout telemetry confirms:

• the weekly reset succeeded and started at 0% usage;
• the primary rate-limit window was 10,080 minutes (7 days);
• usage then rose continuously to 100% in ~44 minutes;
• security discovery workers continued being created as usage approached exhaustion;
• another discovery worker was attempted after the weekly limit was already exhausted;
• the user-facing task reported an old 6% usage reading even though its own final telemetry showed 69%.

This appears related to multi-agent/context amplification and lack of a task-wide usage guardrail.

Steps to reproduce:

1. Start a comprehensive Codex Security assessment of a local Java web application.
2. Allow the security workflow to use its normal Standard discovery-worker orchestration.
3. Let the account reach its Work/Codex usage limit while the security scan is still incomplete.
4. Perform a full weekly usage reset.
5. Resume the interrupted security assessment.
6. Observe worker/subagent creation and weekly usage.

I have not intentionally repeated this because reproducing it would risk consuming another weekly allowance.

Expected behaviour:
At least one of the following should prevent a single automatically orchestrated task from unexpectedly exhausting a complete weekly allowance:

• limit worker/subagent fan-out;
• impose a task-wide usage budget;
• stop creating new workers when account usage becomes critically high;
• require confirmation before restarting or expanding a previously interrupted high-cost task;
• provide an accurate live usage warning;
• apply an appropriate shorter-window safeguard before a complete weekly allowance is consumed.

Actual behaviour:
The local Codex rate-limit telemetry shows the fresh weekly reset beginning at:
used_percent = 0
primary.window_minutes = 10080
secondary = null

The counter then progressed rapidly through the weekly allowance and reached 100% approximately 44 minutes later.

An explicit usage_limit_exceeded error followed seconds afterwards.

The security workflow generated numbered Standard discovery workers through at least discovery-0013 before exhaustion.

Each Standard discovery-worker configuration included:
subagents = 3

discovery-0013 was launched when weekly usage was already approximately 97-98%, yet it was still instructed to run another Standard security scan with subagents.

After the weekly allowance reached 100%, the orchestration later attempted to create discovery-0014. That attempt was blocked by the usage limit.

Across the reset-to-exhaustion window, the recovered telemetry shows dozens of newly created Codex sessions, overwhelmingly security-scan workers and subagents.

Usage-reporting issue:
A diagnostic task eventually reported:

“Current Codex allowance is healthy: 6% used when checked.”

However, the 6% value was an earlier measurement.

By the time that task completed, its own rate-limit telemetry showed approximately:
used_percent = 69

So the final user-facing status materially understated current usage while concurrent agentic work was still running.

Local token telemetry:
The recovered local rollout telemetry records very large aggregate model activity during the reset-to-exhaustion period.

The overwhelming majority was associated with security-scan and subagent sessions.

I am deliberately not treating the raw token count as equivalent to billable credits or weekly allowance units, because the weighting rules are not exposed in these logs.

The important observation is the scale of repeated concurrent model/context processing generated by one security assessment.

Secondary limit:
During the successful security-scan activity, the local rate-limit telemetry repeatedly reported:

primary.window_minutes = 10080
secondary = null

If a shorter/5-hour Work/Codex safeguard is expected to apply to this workload, it does not appear in the captured telemetry.

Questions:

1. Is this level of discovery-worker/subagent fan-out expected for one Codex Security assessment?
2. Should new Standard discovery workers continue being created when weekly usage is already above ~95%?
3. Should a high-cost interrupted scan automatically continue expanding immediately after a fresh usage reset?
4. Are interrupted/retried/replacement workers independently counted toward usage?
5. Is there a task-wide usage budget for multi-agent Codex Security scans?
6. Is secondary = null expected for this workload?
7. Can Codex expose or enforce configurable usage thresholds before spawning additional workers?
8. Could the final task status use the latest rate-limit telemetry instead of repeating an earlier usage reading?

Related issues:

• openai/codex#46023
• openai/codex#39808
• openai/codex-security#849

I have a sanitised evidence PDF containing quota progression timestamps, reset and limit telemetry, worker timeline, the 6%-reported vs 69%-actual discrepancy, and source-log SHA-256 hashes.

I am not posting raw rollout logs publicly because they contain private project data.

What steps can reproduce the bug?

A single requested Codex Security assessment expanded into a large worker/subagent tree and consumed an entire freshly reset weekly Work/Codex allowance in approximately 44 minutes.

Local Codex rollout telemetry confirms:

• the weekly reset succeeded and started at 0% usage;
• primary.window_minutes = 10080 (7 days);
• secondary = null;
• usage then rose continuously to 100% in ~44 minutes;
• an explicit usage_limit_exceeded error followed seconds later.

The security workflow generated numbered Standard discovery workers through at least discovery-0013 before exhaustion.

Each Standard discovery-worker configuration included:

subagents = 3

discovery-0013 was launched when weekly usage was already approximately 97-98%, yet it was still instructed to run another Standard security scan with subagents.

After the weekly allowance reached 100%, the orchestration later attempted to create discovery-0014. That attempt was blocked by the usage limit.

Across the reset-to-exhaustion window, the recovered telemetry shows dozens of newly created Codex sessions, overwhelmingly security-scan workers and subagents.

There was also a usage-reporting problem. A diagnostic task eventually reported:

“Current Codex allowance is healthy: 6% used when checked.”

However, that 6% was an earlier reading. By the time that same task completed, its own rate-limit telemetry showed:

used_percent = 69

So the final user-facing status materially understated current usage while concurrent agentic work was still running.

I have not intentionally reproduced this incident because doing so risks consuming another complete weekly allowance.

Related issues:

• openai/codex#46023
• openai/codex#39808
• openai/codex-security#849

I have a sanitised evidence PDF with the quota timeline, worker timeline, telemetry and source-log hashes. Raw rollout logs are not being posted publicly because they contain private project data.

What is the expected behavior?

A single requested Codex Security assessment should remain within a bounded and understandable resource envelope.

Expected behaviour:

• Worker/subagent fan-out should be limited or budgeted at the parent-task level.
• New Standard discovery workers should not continue being created when weekly usage is already critically high.
• Resuming an interrupted high-cost scan after a reset should not automatically restart or expand large amounts of agentic work without clear user confirmation.
• The task should report current usage accurately using the latest available telemetry.
• If a shorter/secondary usage safeguard applies, it should prevent a single burst of automated multi-agent activity from consuming an entire weekly allowance in under an hour.
• If no shorter safeguard applies, the user should receive a clear warning before additional workers are spawned at very high weekly usage.
• Once the weekly limit is exhausted, the orchestration should stop attempting to create further workers.

Additional information

I have an open OpenAI Support case for the same incident.

I recovered the local Codex rollout telemetry covering the reset, the complete 0% → 100% usage progression, worker/subagent creation, the first usage_limit_exceeded event, and activity attempted after exhaustion.

I also created a sanitised evidence PDF containing:

• the quota timeline;
• worker/subagent timeline;
• relevant telemetry values;
• the stale 6%-reported vs 69%-actual discrepancy;
• SHA-256 hashes identifying the original local rollout logs.

The raw logs are not being attached publicly because they contain private project information. I can provide additional sanitised records or specific telemetry fields if a maintainer requests them.

The GitHub form is also showing potential duplicate issues. I am happy for this report to be linked/merged with an existing issue if one covers the same Codex Security worker-fan-out behaviour.