Chronicle never generates 6-hour summaries — only the 10-minute tier ever runs

Summary

Chronicle's documented file structure describes two summary levels, but only the 10-minute level is ever produced. No 6h summary session is ever started — this is not a job that runs and fails, it is a job that is never queued.

From the documented structure:

<utc_timestamp>-<4_alpha_chars>-10min-<slug>.md  - last 10 minutes, updated every minute
<utc_timestamp>-<4_alpha_chars>-6h-<slug>.md     - last 6 hours, updated every hour

Only the first is ever written.

Environment

• ChatGPT desktop macOS, versions 26.803.41515 and 26.803.61601 (both affected)
• chronicle = true, memories = true
• Log window examined: 2026-07-28 -> 2026-08-11 (continuous daily use)

Evidence

Across all logs in that window:

| Metric | Count |
|---|---|
| starting summary session with level="10min" | 11,848 |
| starting summary session with level="6h" | 0 |
| completed summary session with level="10min" | 959 |
| completed summary session with level="6h" | 0 |
| -10min- files in resources/ | 590 |
| -6h- files in resources/ | 0 |

Every recursive summarizer pass completed line reports the same shape, across ~2,800 passes without a single exception:

recursive summarizer pass completed summary=wrote N ten-minute summaries, 0 six-hour summaries

There are no 6h errors, no failed 6h sessions, and no partial output. The level simply never appears in any log line.

The capability is present in the binary

ChatGPT.app/Contents/Resources/codex_chronicle contains the full 6h prompt path:

• # How to handle longer time window summaries / - For 6h: / Compress the larger arc of work. / Highlight major themes, repeated workflows, and notable pivots.
• Focus on the larger arc of work across the full window.
• a Child summaries: input slot, distinct from the frame/OCR inputs used at the 10min level
• the -6h- filename format
• 10min and 6h as adjacent level values

So the parent level appears implemented but never scheduled.

Possible cause (unconfirmed)

The summariser is recursive. 10min sessions are built from frames/OCR and always log children=0; the 6h level is designed to consume completed 10min summaries as children. Something in the child -> parent promotion never triggers.

Two candidates, neither verifiable from outside the app:

1. Promotion may require a contiguous run of child buckets (nearby strings include run has at least one element, queue is not empty, front element exists). The recorder deliberately pauses on idle (pausing screen recording due to system idle time), so ordinary breaks — meals, meetings, leaving the desk — would fragment any 6-hour window. A gapless 6h run may never occur in normal human use.
2. The level may be dark behind a flag in these builds.

Impact

The 10-minute tier alone is high volume: 236 files / 2.1 MB for a single day. The 6h tier is the only affordable way to read back a day — 4 summaries instead of 236. Without it, day-scale review of Chronicle output is impractical for users and expensive for agents consuming the memories folder.

Frame citations inside 10-minute summaries also dangle once captures are pruned (~6h), so the 6h rollup would be the only durable coarse record. Currently no such record is ever written.

Reproduce

rg -I -o 'starting summary session.{0,200}' ~/Library/Logs/com.openai.codex \
  | sed 's/\\^[\[[0-9;]*m//g' | rg -o 'level=\\"[a-z0-9]+\\"' | sort | uniq -c

ls ~/.codex/memories/extensions/chronicle/resources/ | grep -c -- '-6h-'

Expected: some 6h sessions and files.
Actual: 11848 level=\"10min\" and 0.

Expected behaviour

A 6h summary is written approximately hourly, consuming completed 10-minute summaries, per the documented structure. If a contiguous run of child buckets is genuinely required, promotion should tolerate idle gaps, since those are normal in real use.