Computer History: summary scheduler has no concurrency cap, no failure backoff, and does not halt on out-of-credits — 4x design rate, reproduced on two machines

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

26.915.31029

What subscription do you have?

Plus&Pro

What platform is your computer?

Darwin 27.2.0 arm64 arm

What issue are you seeing?

Summary

The Computer History summarization scheduler enters a runaway state: it launches summary sessions concurrently without a cap, retries failures with no backoff, and continues issuing requests after the backend has returned an out-of-credits response. Over two days this produced 2,324 summary sessions across two machines against a design rate of ~144/device/day (~4x), exhausting the plan allowance on multiple accounts with no user activity and no in-product indication.

This exhausted both the subscription allowance and purchased credits on multiple accounts, and continued to consume each quota window as it reset.

Relationship to #42282

#42282 reports that Chronicle/Computer History consumption is not attributable in any usage surface. This issue is a different failure mode in the same subsystem — the scheduler's rate-limiting and error handling, not its reporting. The two are independent: the runaway behavior below would be a defect even with perfect attribution.

One datapoint that may be useful to #42282: on my accounts the consumption is visible, via Settings → Usage → Analytics → Usage history → By model. It is not labeled as Computer History, but the summarizer's model (gpt-5.5) is distinct from anything used interactively, which makes it separable. See "Server-side confirmation" below.

Environment

• ChatGPT desktop app, macOS, two machines (A and B), Apple Silicon
• Affected version: 26.915.31029
• [features] chronicle = true in ~/.codex/config.toml
• Summarizer invoked as codex exec, model=gpt-5.5, reasoning_effort=medium, working directory = the frame-capture temp dir
• Capture cadence 5000 ms, dropping to 1000 ms when recent user input is detected

Observed rate

Counted from ~/Library/Logs/com.openai.codex/<YYYY>/<MM>/<DD>/, matching starting codex exec summary session:

Date	Machine A	Machine B
09-09	52	—
09-10	223	—
09-11	127	—
09-16	27	13
09-17	707	826
09-18	96	695

2026-09-17 — GPT-5.5 accounts for 94% of plan usage

2026-09-18 — GPT-5.5 accounts for 81%

I have never invoked gpt-5.5 interactively; local thread records for this window show only gpt-5.6-sol, gpt-6-astra and gpt-5.6-luna, each with a real first user message. A control account not signed in on either machine shows no gpt-5.5 usage at all in the same window.

So on 09-17 the background summarizer accounted for roughly 15x my own interactive usage.

Expected behavior

1. A bounded number of concurrent summary sessions (1–2 seems sufficient for a 10-minute bucket cadence).
2. Exponential backoff on failure, and rescheduling of the existing job rather than minting a new session per attempt.
3. Halt the loop on an out-of-credits or 401 response. Retrying against an exhausted allowance cannot succeed and guarantees the next window is consumed by backlog.
4. Bound the backlog — drop or coalesce buckets older than some threshold instead of replaying hours of stale frames.

Workaround

[features] chronicle = false in ~/.codex/config.toml, then fully quit and relaunch the app. Changing the config alone does not terminate the running process.

Verified on app version 26.915.31945: the setting survives the upgrade, and after a full restart the logs show zero starting codex exec summary session entries and zero out-of-credits errors. The runaway behavior above was observed on 26.915.31029.

What steps can reproduce the bug?

Note on this template: this is not an interactive Codex bug, so there is no code snippet and no user-initiated session. Computer History's summarizer runs as a background process (codex_chronicle) that launches codex exec on its own schedule. I've filled in the equivalent identifiers below.

Steps to reproduce

The sustained-loop behavior is deterministic:

1. Enable Computer History ([features] chronicle = true in ~/.codex/config.toml). Use the machine normally so frames are captured.
2. Allow the plan allowance to be consumed — either by normal Codex use or by the summarizer itself.
3. Once the backend starts returning Your workspace is out of credits, watch ~/Library/Logs/com.openai.codex/<date>/:

bash

# launches
grep -h "starting codex exec summary session" *.log | wc -l
# failures
grep -h "out of credits" *.log | wc -l
# failure → next launch interval
grep -hE "summary session failed|starting codex exec summary session" *.log \
  | grep -oE "^[0-9T:.]+Z.*(failed|starting)" | tail -40

Observed: the scheduler does not stop. Each failure is followed by a new launch within 0.5–1.5 ms, a new session_id is minted per attempt rather than rescheduling the existing job, and up to 6–8 codex exec processes are launched within the same millisecond. Failure count exceeds launch count as a result (833 vs 707 on one machine in one day).

Not deterministic: what caused the initial escalation from ~144/day to 700+/day. It began on both machines independently around 09-16/09-17. On one machine ~/.codex/.codex-chronicle-assets-to-install.marker is timestamped 09-16 12:44 local, immediately before the jump — possibly relevant, possibly coincidence.

Session IDs

These are the summarizer's internal session IDs, not conversation IDs. They are per-process counters, so they need the timestamp and machine to be unique:

Timestamp (UTC) | session_id | Outcome -- | -- | -- 2026-09-17T09:39:10.035313Z | 77 | first out of credits 2026-09-17T09:39:11.079Z | 78 | out of credits 2026-09-17T14:24:05.379139Z | 422 | out of credits, relaunched +0.15 ms as 426 2026-09-17T14:24:05.539946Z | 425 | out of credits 2026-09-17T14:24:05.565634Z | 421 | out of credits 2026-09-18T07:36:24.171712Z | 51 | out of credits 2026-09-18T07:48:59.294850Z | 71 | 401 Unauthorized, relaunched +1.4 ms

The codex exec thread for session 71 is 01a0b37d-7747-7153-be84-ddcb11ce2a99 (2026-09-18T07:48:59Z) — that one should be resolvable server-side.

Token / rate limit usage

• Weekly limit: 0% remaining, exhausted twice within the window
• Settings → Usage → Analytics → By model: GPT-5.5 = 94% of plan usage on 09-17, 81% on 09-18 (screenshots above). gpt-5.5 is the summarizer's model and is not used by any interactive session on these accounts.
• 2,324 summary sessions across two machines over those two days, vs. a design rate of ~144/device/day.

Context window usage

Not applicable. Each summary session is a short-lived, non-interactive codex exec over one 10-minute bucket of captured frames — there is no accumulating conversation context. The cost driver is the image input per invocation multiplied by the invocation count, not context growth.

What is the expected behavior?

No response

Additional information

No response

Start by tracing the codex_chronicle background process and its codex exec summary-session scheduler, then reproduce the loop with [features] chronicle = true and the logs under ~/Library/Logs/com.openai.codex/. Done means concurrency is bounded, failures back off without minting sessions, out-of-credits or 401 responses halt scheduling, and stale backlog is bounded or coalesced.