Skip to content

Codex Desktop (macOS): Chronicle runs continuous background screen-recording summaries every 10 min, draining plan limits; disabling doesn't immediately stop capture #30639

Open
Open
Codex Desktop (macOS): Chronicle runs continuous background screen-recording summaries every 10 min, draining plan limits; disabling doesn't immediately stop capture#30639
Labels
appIssues related to the Codex desktop appbugSomething isn't workingcomputer-useconfigIssues involving config.toml, config keys, config merging, or config updatesmemoryrate-limitsIssues related to rate limits, quotas, and token usage reporting

Description

@nathanjohnpayne
nathanjohnpayne
opened on Jun 30, 2026

Component: Codex Desktop app (macOS) — Chronicle / SkyComputerUseService. This is a desktop-app behavior bug, not a model/API issue.

What happened

A Codex Desktop background feature — Chronicle — silently consumed a large share of my plan limits by recording my screen and generating summaries on a timer, with no action from me. In Codex Analytics this shows up as a large "Exec" surface (not "Desktop App"), which made it very hard to attribute — I do not run codex exec or any Codex CLI/CI/cron jobs.

After investigating locally, Chronicle is unambiguously the cause:

  • ~/.codex/memories/extensions/chronicle/resources/ contains 536 files, every one a *-10min-memory-summary.md.
  • Each summary is a ~4 KB vision-model narrative whose ## Citations section references screen-recording frame JPEGs under /var/folders/.../T/chronicle/screen_recording/1min/....
  • So the mechanism is: continuous 1-minute screen recording → a vision-model summary every 10 minutes, indefinitely, as a background "Exec" run.

Why this is a problem

  1. Unattributable usage. Background Chronicle runs are billed under "Exec," indistinguishable in Analytics from intentional CLI use. There is no per-feature breakdown showing "Chronicle consumed N tokens." Image

  2. Volume scales with uptime, not work. Per-day summary counts on my machine:

    Date Summaries
    Jun 22 12
    Jun 23 108
    Jun 24 11
    Jun 25 1
    Jun 26 6
    Jun 27 121
    Jun 28 164
    Jun 29 113

    These map directly onto the largest "Exec" spikes in my usage graph. On Jun 28 it ran in bursts (47 summaries in one hour, 45 the next) — well above the 6/hour a clean 10-minute cadence implies — suggesting backfill/catch-up that multiplies cost.

  3. It runs regardless of activity. Several summaries explicitly note "this window did not show coding work" yet still made a full vision-model call — i.e. it bills for idle/personal screen time.

  4. Privacy. Chronicle captures and summarizes all on-screen content (personal browsing, email, password-manager windows, etc.), not just the active project, and stores ~476 MB of screen frames locally in temp.

  5. Disabling chronicle in config did not stop screen capture immediately. After setting [features] chronicle = false in ~/.codex/config.toml (17:30:36 local), screen frames continued to be written for ~18 minutes (last frame 17:48:48) before capture stopped. The SkyComputerUseService helper process remained resident (idle) afterward. The lag plus the lingering process make it unclear to users whether the feature is actually off, and there is no in-app confirmation that capture has ceased. (Observed correlation; I have not isolated whether the config edit, a recording-chunk boundary, or app state is what ultimately stopped it.)

Environment

  • Codex Desktop (macOS), bundle com.openai.codex
  • Codex CLI present at /opt/homebrew/bin/codex (v0.137.0) — not the source; all 189 local sessions report originator: "Codex Desktop", zero CLI sessions
  • ~/.codex/config.toml:
    • model = "gpt-5.3-codex-spark"
    • model_reasoning_effort = "xhigh"
    • [features] chronicle, memories, multi_agent, hooks

Steps to reproduce

  1. Enable Chronicle in Codex Desktop and leave the app running.
  2. Use the machine normally (or leave it idle) for a few hours.
  3. Observe ~/.codex/memories/extensions/chronicle/resources/ filling with 10min-memory-summary files, each citing screen frames.
  4. Check Codex Analytics → "Exec" usage rises with no CLI/CI activity.

Expected behavior

  • Chronicle's token consumption should be visible and attributed (its own line in usage analytics, or a running token/credit counter in the UI).
  • It should be off by default, with an explicit, clearly-labeled opt-in that states it screen-records continuously and makes a model call every 10 minutes.
  • Setting chronicle = false (or toggling it off in the UI) should immediately stop screen capture and the SkyComputerUseService process — not just the summary loop.
  • It should not summarize windows with no project activity, and should respect a do-not-capture / pause control.

Requests

  1. Add per-feature usage attribution (especially Chronicle) to Codex Analytics.
  2. Make Chronicle opt-in with a clear cost/privacy disclosure.
  3. Ensure disabling Chronicle fully stops capture immediately, and document the exact off switch (incl. the macOS Screen Recording permission).
  4. Consider crediting back usage consumed by background Chronicle runs users did not knowingly enable.

I have local evidence (file listings, cadence histograms, a sample summary with frame citations) and can share redacted versions on request.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    computer-use
    memory
    rate-limitsIssues related to rate limits, quotas, and token usage reporting
    configIssues involving config.toml, config keys, config merging, or config updates
    on Jun 30, 2026
  2. nathanjohnpayne
    changed the title [-]Chronicle generates continuous background "Exec" model usage (10-min screen-recording summaries) that drains plan limits; disabling in config doesn't stop screen capture[/-] [+]Codex Desktop (macOS): Chronicle runs continuous background screen-recording summaries every 10 min, draining plan limits; disabling doesn't immediately stop capture[/+] on Jun 30, 2026

  3. github-actions commented on Jun 30, 2026

    @github-actions
    github-actionsbot
    on Jun 30, 2026 – with GitHub Actions
    Contributor

    Potential duplicates detected. Please review them and close your issue if it is a duplicate.

    Powered by Codex Action

  4. nathanjohnpayne commented on Jun 30, 2026

    @nathanjohnpayne
    nathanjohnpayne
    on Jun 30, 2026
    Author

    Additional local findings (2026-06-30) that were not in body yet:

    • I re-ran diagnostics after setting chronicle = false and still see significant background telemetry churn on this machine, but pgrep -f codex_chronicle is currently empty (no codex_chronicle process).
    • SkyComputerUseService is still running:
      • /Users/nathanpayne/.codex/computer-use/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService
    • Codex.app is still running with helper processes (multiple Codex (Service)/Codex (Renderer)/node_repl processes).
    • launchd has active Codex updater jobs (com.openai.codex-sparkle-updater and com.openai.codex-sparkle-progress) on this host.
    • Focused filesystem check from same timeframe:
      • ~/.codex modified files: 29 (last 1h), 786 (last 24h)
      • memories/: 747 (last 24h)
      • sessions JSONL: 2 (last 24h)
      • ambient-suggestions/: 2 (last 24h)
    • Session metadata in recent files still shows desktop-origin sessions as source, e.g. originator: "Codex Desktop", source: "vscode".
    • I also see repeated local summary-job failure warnings that include the usage-limit message in this loop context (e.g. You've hit your usage limit... with shell snapshot deletion warnings), which may indicate how the background loop handles exhaustion rather than cleanly stopping.

    So one likely interpretation from this repro window is: even after Chronicle is toggled off, other background desktop/runtime services (including memory suggestions / session/process-manager surfaces) can keep writing to .codex and generating analytics surfaces. If useful, I can run a narrow feature-by-feature toggle matrix and share deltas.

  5. nectosoft commented on Jun 30, 2026

    @nectosoft
    nectosoft
    on Jun 30, 2026

    Are there any improvements by proxy with the new bug fixing update today?

  6. TheProcrastinatingViking commented on Jun 30, 2026

    @TheProcrastinatingViking
    TheProcrastinatingViking
    on Jun 30, 2026

    I only see changes to my weekly (its now moderate instead of fast), daily is still draining extremely fast, 1 task took 46% daily usage & was 23 minutes 58 seconds long

  7. HelloThisIsFlo commented on Jul 19, 2026

    @HelloThisIsFlo
    HelloThisIsFlo
    on Jul 19, 2026

    I'm sharing this as an additional diagnostic data point rather than a complaint. I've otherwise had an excellent experience with Codex.

    I enabled Chronicle on 10 July 2026 at approximately 21:13 BST. Screen capture appears to have begun at about 21:10.

    The attached Codex Analytics graph covers 20 June through 19 July:

    • The tooltip for 10 July shows 98% Desktop App, 2% Mobile, and 0% Exec.
    • Exec first appears in the next daily bucket, around 11 July.
    • It remains present every day afterward and becomes a substantial portion of my usage.
    • On the latest day shown, visible Desktop App activity is almost zero while the majority of recorded activity is attributed to Exec.

    This coincides with my weekly allowance apparently dropping by approximately 15–20% overnight, despite me not actively using Codex during that period.

    OpenAI's recent global reset and the availability of Banked Resets have been very generous, so this has not prevented me from continuing to use Codex. Since enabling Chronicle, however, I have used at least two Banked Resets, in addition to the global reset. I mention this only as context for the scale of the usage; I cannot attribute all of that consumption to Chronicle.

    I understand that:

    • The graph's percentage scale does not necessarily equal percentage points of plan allowance.
    • The next-day boundary could be explained by UTC bucketing, processing time, or Analytics reporting delay.
    • Temporal correlation alone does not prove causation.

    However, the combination of roughly three weeks without Exec usage, Chronicle activation at a known time, and persistent Exec usage beginning immediately afterward seems consistent with the mechanism reported in this issue.

    I can follow up with a Chronicle-disabled comparison after fully restarting Codex to see whether the unexplained Exec usage stops.

    Environment:

    • ChatGPT Pro
    • Codex Desktop on macOS

    I have only attached the Analytics graph, not any Chronicle summaries or captured frames, because those contain private screen content.

    Image

  8. beyejin commented on Aug 26, 2026

    @beyejin
    beyejin
    on Aug 26, 2026 – with ChatGPT Codex Connector

    Additional reproduction on 2026-08-27 (KST) with Codex Desktop 26.820.60940 on macOS 26.6.2.

    I investigated because my remaining Codex usage appeared to decrease when I was not intentionally running a background job. The two local scheduled automations I found were both PAUSED, and no separate active scheduled task was present. However, the local configuration had:

    [features]
memories = true
chronicle = true

[memories]
generate_memories = true
use_memories = true

    A resident codex_chronicle process was present. The local Codex logs then showed a separate system-generated background thread (not present in the normal user-visible thread list):

    • cwd: ~/.codex/memories
    • model: gpt-5.6-terra
    • reasoning effort: medium
    • internal prompt: Memory Writing Agent: Phase 2 (Consolidation)
    • thread id: 01a03f23-9168-76c2-8a2c-0a60fb3b4270

    The thread repeatedly emitted run_sampling_request entries and performed memory consolidation/file updates. Its internal post sampling token usage counter increased from 54,036 at 02:35:01 KST to 145,779 at 02:40:26 KST while the user was not interacting with that background worker. I am not treating that counter as a direct billing amount; please correlate it with the account-level usage records.

    Expected behavior: background Chronicle/memory work should be clearly visible, bounded, opt-in, and separately attributed. It should not silently consume a user's plan allowance, and disabling it should stop the worker immediately.

    Please confirm whether this background memory/Chronicle activity is metered against Codex usage and consider restoring any allowance consumed without an intentional user-started task. I can provide sanitized log excerpts and timestamps privately if needed.

  9. axisrow commented on Aug 30, 2026

    @axisrow
    axisrow
    on Aug 30, 2026

    +1, I'll write about this on Reddit — I suspect it'll get a lot of attention.

    Image

    There's no "Exec" entry at all in my ccusage logs... so this looks like a silent billing skip rather than a visible one.

    Image

    Either way, my limits ended up completely drained.

    Image

    This looks like the same root cause reported in several other open issues — possible duplicates or close variants of this one:

    And related (same "silent background drain" pattern, not necessarily Chronicle specifically):

  10. axisrow commented on Aug 30, 2026

    @axisrow
    axisrow
    on Aug 30, 2026

    Filed a follow-up specifically about the transparency gap this exposed: #41617 — the core issue isn't just Chronicle's background drain, it's that there's no reconcilable local/server-side record of what consumed quota at all.

  11. axisrow commented on Aug 30, 2026

    @axisrow
    axisrow
    on Aug 30, 2026

    +1, hitting the same thing under the current "Computer History" naming (same feature, renamed from Chronicle). Quota was silently drained on 2 consecutive days — Aug 29 and Aug 30 — with the same pattern described above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingcomputer-useconfigIssues involving config.toml, config keys, config merging, or config updatesmemoryrate-limitsIssues related to rate limits, quotas, and token usage reporting

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions