Skip to content

Codex Desktop scheduled automation can replay 128K–146K context per call and consume >1.08M tokens in under a minute #42702

Open
Open
Codex Desktop scheduled automation can replay 128K–146K context per call and consume >1.08M tokens in under a minute#42702
Labels
appIssues related to the Codex desktop appautomationsbrowserbugSomething isn't workingcomputer-usecontextIssues related to context management (including compaction)rate-limitsIssues related to rate limits, quotas, and token usage reportingwindows-osIssues related to Codex on Windows systems

Description

@Jakkarin201043
Jakkarin201043
opened on Sep 4, 2026

What version of the Codex App are you using?

Observed runtime: Codex Desktop 26.901.22334, embedded CLI 0.153.0

What subscription do you have?

Paid ChatGPT plan with Codex access

What platform is your computer?

Windows 10.0.26100 x64

What issue are you seeing?

I observed a severe usage-accounting / context-replay problem in Codex Desktop involving a scheduled automation attached to an older thread.

A single scheduled automation run completed in about 54 seconds but caused 8 model sampling rounds. Each round carried roughly 128K–146K input tokens, even though the actual task was only to check whether an OpenAI Support conversation had received a reply.

The cumulative turn usage reached:

input_tokens:             1,081,077
cached_input_tokens:        944,128
output_tokens:                1,394
reasoning_output_tokens:        719
total_tokens:             1,082,471

The model was gpt-5.6-luna with reasoning effort low.

The input/context grew across the same single turn approximately as follows:

23:00:36Z  ~128,087 cumulative tokens
23:00:42Z  ~256,466
23:00:48Z  ~385,033
23:00:54Z  ~513,747
23:01:02Z  ~647,515
23:01:08Z  ~789,849
23:01:15Z  ~935,980
23:01:23Z  ~1,082,471

The scheduled automation was a heartbeat-style job that ran every 6 hours to check for a support reply. During this one run, the thread repeatedly invoked browser/computer-use tooling and re-sent a very large conversation/tool context on every model round.

This produced a visible, sudden increase in Codex/CLI usage despite the user doing almost nothing interactively at the time. It also matches the broader symptom described in #28908, where usage appears to decrease while Codex is otherwise idle.

Important local evidence

  • The affected automation run was triggered from an older saved Desktop thread.
  • The automation itself was very small: check for a support reply and stop monitoring once a reply exists.
  • The run made 8 model calls in ~54 seconds.
  • The payload was dominated by cached/replayed input context rather than model output.
  • One browser/computer-use observation returned a very large tool result, and subsequent rounds continued to carry the accumulated thread/tool context.
  • After the automation was deleted, local Codex session logs stopped showing new usage from that source.
  • No other active automation remained after cleanup.
  • The local config used gpt-5.6-luna, reasoning low; Fast/Priority mode had also been enabled earlier but was later disabled. Regardless of service tier, the context replay itself appears disproportionate to the tiny task.

For mitigation I changed the default model to gpt-5.6-sol, kept reasoning at low, disabled the explicit priority service tier, and set:

model_auto_compact_token_limit = 100000
model_auto_compact_token_limit_scope = "total"

This is only a local mitigation; it does not address the underlying behavior of scheduled/old threads repeatedly replaying huge context.

What steps can reproduce the bug?

The exact trigger may depend on a long-lived thread, but the observed sequence was:

  1. Create or resume a Codex Desktop thread with substantial prior history/tool output.
  2. Add a scheduled heartbeat/automation to that thread (in this case every 6 hours).
  3. Let the scheduled run wake the old thread.
  4. Have the run use Browser/Computer Use to inspect a page.
  5. Observe token_usage_record entries after each tool/model round.
  6. The same large historical/tool context is re-sent repeatedly, causing cumulative input usage to exceed 1M tokens within about a minute for a very small task.

Expected behavior

A small scheduled check should have bounded context cost. Old thread history and large browser/tool outputs should be compacted, summarized, or excluded before repeated model rounds. Cached/replayed context should not cause a tiny automation to consume an extreme fraction of a user's shared Codex allowance.

The product should also make it obvious when an automation is responsible for usage that occurs while the user is otherwise idle.

Actual behavior

The scheduled run repeatedly reprocessed a ~128K–146K-token context across 8 model rounds, reaching >1.08M cumulative tokens in ~54 seconds while producing only ~1.4K output tokens.

Related issue

Additional diagnostic data

I have the exact local thread/turn identifiers and full token_usage_record timestamps available for OpenAI engineers if a private channel is preferred. I intentionally omitted private account details, local file paths, support-chat content, and full thread identifiers from this public issue.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    automations
    contextIssues related to context management (including compaction)
    rate-limitsIssues related to rate limits, quotas, and token usage reporting
    browser
    computer-use
    on Sep 4, 2026

  2. github-actions commented on Sep 4, 2026

    @github-actions
    github-actionsBot
    on Sep 4, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. 271830740-dev commented on Sep 20, 2026

    @271830740-dev
    271830740-dev
    on Sep 20, 2026

    Codex Desktop feedback: DONT_NOTIFY heartbeat turns are visible and consume model usage

    Date: 2026-09-20 (Asia/Shanghai)

    Environment: Codex Desktop on Windows 11 Pro 64-bit (build 26200); bundled/current CLI reports codex-cli 0.155.0-alpha.9.2.

    Related existing reports: #42702 (scheduled automation context replay and extreme token accounting) and #34974 (repetitive heartbeat updates becoming full chat turns).

    Summary

    Codex Desktop heartbeat automations create a full model turn on every scheduled run. The heartbeat protocol requires a non-empty assistant final response even when the result is DONT_NOTIFY. Those supposedly silent final responses are persisted/displayed in the task and consume model context/usage.

    This is not a one-off prompt mistake. A sanitized audit of one Windows machine's available local session files from July 2026 through 2026-09-19 found 563 unique assistant heartbeat final responses across 20 anonymized automation cases, including 500 DONT_NOTIFY responses. The current incident alone generated 34 observed heartbeat replies in about 3 hours 23 minutes (31 DONT_NOTIFY, 3 NOTIFY) from a five-minute schedule.

    User impact

    • The task appears to send repeated messages even when its saved prompt explicitly says to remain silent unless action is required.
    • Every unchanged-state poll still wakes the model, loads a large task context, and consumes usage.
    • High-frequency heartbeats can therefore produce substantial model-token accounting while producing no user value. The relationship between these diagnostic counters and billed quota requires vendor confirmation.
    • Writing human-readable status text inside the mandatory DONT_NOTIFY envelope makes the client-side visibility problem worse, but removing that text would not remove the model invocation or usage cost.

    Raw session logs were not attached because they contain private business context. Automation identifiers have also been replaced with neutral case labels. This report contains only aggregate counts, dates, and the minimal reproduction.

    Minimal reproduction

    1. Create a thread heartbeat with a five-minute recurrence.
    2. In its prompt, instruct it to notify only for meaningful change, failure, completion, or required user action; otherwise remain silent.
    3. Let the scheduler fire while monitored state is unchanged.
    4. The model is still invoked and must emit a non-empty heartbeat final response containing DONT_NOTIFY.
    5. Observe that the response is stored/shown in the task and the turn consumes model usage.

    Expected behavior

    • DONT_NOTIFY should be consumed by the scheduler/client and never appear as a user-visible task message or notification.
    • Preferably, an unchanged-state heartbeat should not invoke a full conversational model turn at all. Local/event-driven checks should be able to return “no change” before model invocation.
    • The UI should disclose the estimated model-usage impact before enabling a high-frequency thread heartbeat.

    Actual behavior

    • A full model turn is created for every heartbeat tick.
    • The heartbeat response contract forces a non-empty final assistant payload even for DONT_NOTIFY.
    • The client persists/displays these responses, so “silent” is not silent.
    • Repeated turns accumulate context and usage.

    Sanitized local evidence

    The following counts were extracted from the available local Codex session JSONL files on one machine by selecting top-level assistant final responses containing heartbeat decisions and deduplicating by assistant message ID. The search covered available files from July 2026 through 2026-09-19. These counts are a lower bound on visible finals, not an exact count of scheduler ticks or model invocations: missing/compacted files, paused intervals, and deduplication can reduce the observed total.

    Anonymous case DONT_NOTIFY NOTIFY
    CASE-01 160 10
    CASE-02 67 26
    CASE-03 54 0
    CASE-04 46 4
    CASE-05 46 1
    CASE-06 44 1
    CASE-07 31 3
    CASE-08 10 1
    CASE-09 10 3
    CASE-10 8 1
    CASE-11 7 0
    CASE-12 5 1
    CASE-13 4 2
    CASE-14 3 1
    CASE-15 2 1
    CASE-16 1 1
    CASE-17 1 1
    CASE-18 1 0
    CASE-19 0 5
    CASE-20 0 1
    Total 500 63

    Current incident evidence:

    • Anonymous case: CASE-07
    • Schedule: every five minutes
    • Observed window: 2026-09-19 20:15Z to 23:38Z
    • Unique assistant heartbeat finals: 34
    • Session file count involved: 1
    • The automation has now been paused.

    One compacted diagnostic event in the incident recorded more than 2.1 million raw turn tokens including cached input. This is a diagnostic counter, not a claim about billed credits, but it demonstrates the context amplification risk.

    Confirmed local observations and root-cause hypothesis

    The local evidence confirms that scheduled heartbeat inputs and assistant heartbeat finals recur, that many finals contain DONT_NOTIFY, that those finals are present in the task record, and that raw model-token counters advance. Based on that evidence, the following product-mechanism explanation is the leading hypothesis and requires vendor confirmation:

    1. Scheduler design hypothesis: a thread heartbeat appears to invoke the conversational model rather than first running a lightweight local/event-driven predicate.
    2. Protocol/UI mismatch hypothesis: the observed response contract produces a non-empty XML final response for DONT_NOTIFY, and the client appears not to suppress that response before persisting/displaying it.
    3. Configuration amplification: a five-minute recurrence and a long monitoring prompt multiply context usage. In this incident, human-readable text was also placed inside DONT_NOTIFY, making the visibility defect more disruptive.

    In the observed runs, the saved prompt’s “remain silent when unchanged” instruction did not prevent the scheduled turn or the persisted final response.

    Requested product changes

    1. Suppress DONT_NOTIFY heartbeat finals before chat persistence, rendering, and notification delivery.
    2. Add a scheduler-level no-model result path for unchanged state, preferably using local/event-driven predicates.
    3. Do not load full thread history for routine heartbeat polling unless escalation is required.
    4. Default heartbeat notification policy to failed runs only, and make it clear that notification policy does not eliminate model usage.
    5. Warn users about estimated invocation frequency and usage before enabling sub-hourly heartbeats.
    6. Add deduplication/rate limiting so repeated unchanged-state checks do not create separate conversational turns.
    7. Provide a supported local watchdog mode that can escalate to a model only on a verified state transition.

    Local mitigation already applied

    • Paused the incident heartbeat 1163850043.
    • Paused the two remaining active thread heartbeats (c-b-c and obsidian).
    • Confirmed that business automations were not paused.
    • Policy going forward: no heartbeat is considered silent if it invokes a model. Monitoring should run locally without a model and escalate only on verified exceptions.

    Privacy statement

    No passwords, tokens, cookies, OTPs, session contents, customer data, or raw business records are included in this report.

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 appautomationsbrowserbugSomething isn't workingcomputer-usecontextIssues related to context management (including compaction)rate-limitsIssues related to rate limits, quotas, and token usage reportingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions