[Codex App] Background thread-description backfill creates thousands of hidden requests and causes 429s
What version of the Codex App are you using (From “About Codex” dialog)?
26.818.61809
What subscription do you have?
Pro 20X
What platform is your computer?
Darwin 25.2.0 arm64 arm (macOS 26.2, Apple Silicon)
What issue are you seeing?
The Codex App appears to run a large background backfill that generates search-oriented descriptions for existing threads.
On August 27, 2026, it created at least 1,710 hidden, read-only utility sessions between 09:36:07 and 20:28:40 (Asia/Shanghai). The generated prompt begins with:
You are in a fork of an existing Codex thread. Fill the structured description field with a compact, search-oriented summary...
Every observed utility session executed with gpt-5.6-luna at low effort even though thread_settings.model was None. These were not user-initiated model selections.
The background work overlapped directly with foreground traffic:
- The first upstream 429 for both
gpt-5.6-solandgpt-5.6-lunaoccurred in the same second, at 15:23:43. - From 15:23 through 15:32, the upstream returned 126 Sol 429s and 56 Luna 429s.
- Additional overlapping bursts occurred at 17:32 and 18:02.
- From the beginning of the backfill through 20:28, the upstream returned 241 total 429 responses: 175 for Sol and 66 for Luna.
- After Codex retries, 66 Luna sessions and 4 Sol sessions still ended with a final 429.
- The last Luna 429 was at 18:02:35; the last Sol 429 was at 19:58:47. Both models were returning HTTP 200 again by 20:28.
A transparent local proxy was present only to inspect routing. Its request ledger records provider=openai and errorCode=rate_limit_exceeded. It did not synthesize the 429 responses.
What steps can reproduce the bug?
- Have a large local Codex task history (approximately 1,600 threads in this case), including archived threads without retrieval descriptions.
- Launch the Codex App and access the task history.
- Observe background fork sessions created to fill a structured description field for existing threads.
- Continue normal foreground work while the backfill runs.
- Inspect Codex logs: the background sessions use
gpt-5.6-luna, receive HTTP 429 withRetry-After, and foreground requests share the affected rate limit.
The exact UI trigger is uncertain because the backfill began automatically. The user did not select Luna for these calls.
What is the expected behavior?
Background metadata generation should be lazy and rate-limited. It should obey Retry-After, use bounded concurrency/RPM, pause or yield to foreground work, and isolate failures so that indexing cannot exhaust the account rate limit or disrupt normal user tasks.
Additional information
Affected period observed so far: August 27, 2026, 09:36:07–20:28:40 (Asia/Shanghai).
Codex App version observed during the incident: 26.818.61809.
Codex runtime reported during the incident: 0.149.0-alpha.4.
Likely component: Codex App thread-description / retrieval-index backfill scheduler.
The exact quoted prompt is generated by Codex itself. No account IDs, access tokens, API keys, session IDs, or private task contents are included.