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

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

• #28908 — Codex usage limit decreases without corresponding user activity

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.

Start with the scheduled automation path and the token_usage_record entries in the local session logs; compare the eight model/tool rounds and their repeated context sizes. Done means identifying why the old thread and large tool results are replayed across rounds, then demonstrating bounded usage for the small scheduled check.