Chronicle background captures consume quota with no attribution in any usage surface (repro script included) #42282

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

26.825.51511

What subscription do you have?

Plus (was Pro until Aug 23, 2026)

What platform is your computer?

Darwin 25.5.0 arm64 (macOS 26.x, Apple Silicon)

What issue are you seeing?

The Chronicle research preview captures display frames in the background and
periodically summarizes them via codex exec sessions. Those sessions consume
the account's rate-limited quota, but they do not appear in any usage surface
available to the user:

• not in Settings → Usage
• not in per-conversation usage breakdowns / "Top consuming chats"
• not in any local token record (no rows in the threads table, no rollout
  files, nothing under the chronicle temp directory)

The result is quota consumption that cannot be attributed by the person paying
for it. Over the 8 days still retained in my local logs, this accounted for
82,791 captured frames and 6,002 background summary sessions. Local artifacts
indicate the pipeline had been running since at least June 21, 2026.

Two secondary observations:

1. The settings page that controls this feature is only reachable while the
   feature is enabled. After disabling it, the page is no longer present, so a
   user who suspects it cannot go back and confirm its state from the UI.

2. Consent persists across app updates. chronicle-consent-accepted remained
   true in global state, and the capture process started automatically after an
   update without re-prompting.

I want to be precise about what is and is not being reported here. The token
cost WAS disclosed — the Chronicle documentation had a "Rate limits" section
stating these agents "consume rate limits quickly." This report is not about
disclosure. It is about attribution: once running, there is no surface, local
or remote, where a user can see that this specific feature is what consumed
their quota.

What steps can reproduce the bug?

1. Enable the Chronicle research preview (ChatGPT desktop, macOS).
2. Leave the app open and do not send any prompts.
3. Observe in ~/Library/Logs/com.openai.codex/YYYY/MM/DD/:
   grep -c 'wrote sparse memory frame' → frames captured
   grep -c 'starting codex exec summary session' → background model calls
4. Sample GET /backend-api/wham/usage before and after a 30-minute idle period.
   used_percent increases with no user-initiated activity.
5. Compare against Settings → Usage for the same window: the consumption from
   step 3 is not attributable to any listed item.

A read-only script that performs steps 3–4 and reports the counts:
https://github.com/hankwangtw/chronicle-quota-check

What is the expected behavior?

Any feature that consumes rate-limited quota should be attributable in a usage
surface the account holder can read — ideally a per-feature line item, at
minimum an aggregate "background activity" bucket that is visibly non-zero.

Without that, a user who notices quota disappearing has no path to a diagnosis:
they cannot tell background summarization apart from delayed accounting, from a
stuck task, or from unauthorized access to their account.

Additional information

Full write-up with the controlled on/off comparison, the 70-day timeline and raw logs: https://machblink.com/chronicle

This may explain some of the macOS idle-drain reports in #30525 and #31165,
and it overlaps with the attribution request in #41617.

Earlier reports of the same mechanism: #23124, #26808, #27773.

Note on the August 24 fixes: those addressed high p95 usage in Computer
History, the rebuilt successor to Chronicle. On this machine the older
Chronicle screenshot pipeline was still running as of August 30, seventeen
days after Computer History shipped, which suggests the migration does not
always take effect on existing installations.

I also raised this through the help center support flow on August 26 and 28.
The conversation was escalated on August 28 with a note that a reply would
follow within a few days; as of this writing none has arrived. Full transcript
available if useful.

Disabling the feature stopped the consumption immediately and it has not
resumed (measured: quota at 0% used across consecutive 10-minute samples with
the app open and no user activity).