Codex Desktop 26.930.31730: default memory generation fans out into hidden agents and consumes ~15% of 5-hour quota after a 2-minute task #51177

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   memory

   subagentIssues involving subagents or multi-agent featuresIssues involving subagents or multi-agent features

   rate-limitsIssues related to rate limits, quotas, and token usage reportingIssues related to rate limits, quotas, and token usage reporting

   on Oct 5, 2026
2. eengert commented on Oct 5, 2026

   

   eengert

   on Oct 5, 2026 – with ChatGPT Codex Connector

   Author

   More actions

   Controlled A/B follow-up: disabling memory generation eliminated the runaway background workload

   I performed an immediate controlled follow-up after applying the workaround:

   [memories]
   generate_memories = false
   use_memories = true

   Then I updated/restarted Codex Desktop, archived the prior test thread, and started a brand-new Sol-6.1 / Low thread for another tightly bounded task.

   Verification before the test

   The restarted app had loaded:

   generate_memories = false
   use_memories = true
   

   New run

   Foreground/user task:

   17:13:50  gpt-6.1-sol / low starts
   17:14:49  foreground task finishes
   

   Observed background activity during and after the task:

   gpt-6.1-sol:
     one foreground/user turn
     max observed sampling usage: 73,115
   
   gpt-6-luna:
     one ~3-second title-generation turn
     max observed sampling usage: 17,841
   
   gpt-5.6-terra:
     NONE
   
   memory generation/consolidation:
     NONE
   
   ~/.codex/memories activity:
     NONE
   
   codex-auto-review sampling:
     NONE
   

   I continued observing after the foreground task had completed. Through at least 17:16:07, there was still:

   • no Terra inference;
   • no memory stage-1 extraction;
   • no memory consolidation;
   • no memory workspace activity;
   • no delayed Auto Review sampling.

   Quota result

   Persisted Codex usage history showed:

   before controlled run: 17% used / 83% remaining
   after controlled run:  19% used / 81% remaining
   

   So this comparable fresh-thread test consumed approximately 2 percentage points, versus approximately 15 percentage points in the prior run with default memory generation enabled.

   Before/after comparison

   BEFORE
   generate_memories = default (true)
   one short Sol task
   → hidden Terra memory workers
   → hidden memory-consolidation agent
   → hidden Terra subagent
   → Luna metadata jobs
   → Auto Review turns
   → ~15% of 5-hour allowance consumed
   
   AFTER
   generate_memories = false
   use_memories = true
   one short Sol task
   → Sol foreground turn
   → one tiny Luna title-generation turn
   → no Terra/memory workload
   → ~2% of 5-hour allowance consumed
   

   This is a strong A/B indication that the runaway consumption in the original incident was caused primarily by background memory generation/consolidation, not by the foreground Sol task itself.

   The workaround also preserves existing memory usage via use_memories = true, so it appears possible to retain memory context while preventing the expensive background generation pipeline.
3. wadofmeat commented on Oct 7, 2026

   

   wadofmeat

   on Oct 7, 2026 – with ChatGPT Codex Connector

   More actions

   Adding a Windows reproduction from October 7, 2026 that appears consistent with this issue.

   Environment / observed behavior:

   • Product: Codex in the ChatGPT desktop app on Windows
   • ChatGPT-authenticated workspace
   • Foreground model: GPT-6 Luna (not Astra / highest-frontier model)
   • User reports one normal Codex prompt this morning exhausted the active 5-hour Codex usage window
   • No intentional use of Astra/highest-frontier model during the run
   • The user had recently enabled local_thread_store_compression = true, but that appears to be local zstd rollout-file compression and should not itself invoke model inference
   • The config did not intentionally enable a special memory workload; this may therefore have been using the default memory behavior described in the original report

   This is notable because the visible workload/model choice does not appear proportionate to exhausting an entire 5-hour allowance.

   The user is preserving the remaining reset(s) rather than repeatedly reproducing the problem. We are also disabling background memory generation as a mitigation while keeping memory reads enabled:

   [memories]
   generate_memories = false
   use_memories = true

   It would be useful if OpenAI can confirm whether server-side logs for affected Windows/Desktop sessions show hidden memory-generation / memory-consolidation / subagent work charging the primary 5-hour bucket, or whether there is also a broader quota-accounting regression.

   If maintainers need additional diagnostic fields (Desktop/Codex build number, local telemetry paths, timestamps, or before/after usage screenshots), I can provide those from the affected machine.

   👍React with 👍1Reacted by Rebroad
4. rebroad commented on Oct 8, 2026

   

   rebroad

   on Oct 8, 2026 – with ChatGPT Codex Connector

   More actions

   Fixed in rebroad/codex commit 12bf4eab8d: memory consolidation now disables Feature::MultiAgentV2 and sets agents_enabled = false, alongside the existing legacy Feature::Collab disable. This prevents the consolidation worker from being given collaboration tools (including spawn_agent), avoiding failed spawns and recursive fan-out.
5. Silver-Acid commented on Oct 14, 2026

   

   Silver-Acid

   on Oct 14, 2026 – with ChatGPT Codex Connector

   More actions

   I'd like to add a UI/UX request alongside the quota and memory-worker safeguards discussed here: Codex Desktop needs a unified, visible indicator for background model activity, not just a memory-specific warning.

   At the moment, the foreground task can appear finished or idle while memory consolidation, metadata generation, auto-review, or spawned background agents continue making model calls. If those calls use the user's allowance, the UI should make that visible.

   A practical design could include:

   1. Persistent global activity indicator — a subtle animated icon in the app's title/status area whenever background inference is running, including after the foreground task ends. It should distinguish foreground activity from background activity.
   2. Expandable task details — clicking the indicator shows each active/recent task's purpose (e.g. memory extraction, memory consolidation, auto-review), model, status, elapsed time, and parent task/subagent relationship. A useful lifecycle would be queued / running / completed / failed / cancelled.
   3. Usage attribution — show foreground vs. background usage, and the tokens or estimated quota impact per task, plus recent history. If exact per-task quota attribution isn't available, label it as an estimate rather than implying precision.
   4. User controls and budgets — a discoverable way to pause/stop background generation, adjust memory generation separately from memory use, and enforce a background usage limit or remaining-quota threshold without editing config.toml.
   5. Abnormal-activity visibility — surface when background work continues significantly after the visible task completes or fans out into additional agents, rather than letting quota silently decrease.

   This does not require showing private chain-of-thought or internal prompts: task metadata and resource consumption are enough.

   The central issue is observability and user control. Even if the excessive Terra fan-out is fixed, users should be able to tell what Codex is doing in the background, why it is running, and whether it is consuming their interactive quota.
6. CipherGreyLabs commented on Oct 16, 2026

   

   CipherGreyLabs

   on Oct 16, 2026

   Last edited by CipherGreyLabs

   More actions

   Second environment, same signature — with proxy-side per-request telemetry

   Adding an independent confirmation from Windows 11 x64 on Codex CLI/Desktop 0.162.0-alpha.17.2, ChatGPT auth, memory behaviour left at defaults (generate_memories = true, use_memories = true; no [memories] override at the time of these observations).

   The useful difference from the report above: this machine runs Codex behind a local OpenAI-compatible proxy (model_provider points at a loopback Responses endpoint). Every inference request Codex makes is therefore logged with provider, model, requested effort, conversation id, duration and HTTP status. Hidden threads stop being hidden.

   What the proxy log shows while only one foreground thread is active

   While a single foreground thread ran on gpt-6.1-sol, the proxy logged concurrent requests for gpt-5.6-terra at effort medium — and all of them carried the same conversation id, distinct from the foreground thread's id:

   01:34:54  gpt-5.6-terra  medium  thread <consolidation>  7718 ms  200
   01:35:02  gpt-5.6-terra  medium  thread <consolidation>  7698 ms  200
   01:35:10  gpt-5.6-terra  medium  thread <consolidation>  3999 ms  200
   

   Three multi-second inference runs inside 16 seconds, on a model nobody selected.

   A separate 4-minute window with exactly one foreground thread running on a non-OpenAI model still produced two hidden gpt-5.6-luna at effort low:

   01:40:19  gpt-5.6-luna  low  thread <foreground>  14872 ms  200
   01:40:19  gpt-5.6-luna  low  thread <foreground>  12945 ms  200
   

   Correlation with <CODEX_HOME>/memories

   The memory files were rewritten in the same minute as the Terra burst:

   <CODEX_HOME>/memories/MEMORY.md           250,979 B   rewritten 01:34
   <CODEX_HOME>/memories/memory_summary.md     65,960 B   rewritten 01:34
   <CODEX_HOME>/memories/raw_memories.md      297,958 B   rewritten 01:30
   

   This matches the finding above that the Terra threads are memory-generation/consolidation work under ~/.codex/memories, and matches the documented pipeline shape: an extract phase asking for gpt-5.6-luna at low, and a consolidation phase asking for gpt-5.6-terra at medium.

   Multi-month trend (the part that is hard to see per-incident)

   Aggregated from the same proxy log. Mean durationMs per request, so this is a workload proxy rather than a token count:

   month	gpt-5.6-terra runs	mean	gpt-5.6-luna calls	mean
   2026-07	93	10,944 ms	1,379	12,193 ms
   2026-08	1,371	12,986 ms	25,017	12,266 ms
   2026-09	1,197	13,604 ms	36,885	11,613 ms
   2026-10	573	16,060 ms	149	28,720 ms

   Per-run work is rising steadily (Terra +47% July → October), on a roughly stable ~20–75 Terra runs per day. The October luna row is also interesting: volume collapsed while mean duration more than doubled, which is what you would expect if the cheap per-turn helper traffic stopped and the remaining calls are the longer extract work.

   One controlled measurement, and its limit

   With the client idle for 10 minutes and no foreground turns, the proxy log gained zero new requests and the account's 5-hour and weekly meters were unchanged. So idle alone does not drain anything here — the consumption tracks foreground work, which is consistent with this issue's trigger.

   Not measured: I could not capture a successful turn on a second client transport I have configured, because those turns currently fail before completion on this machine. I therefore make no claim about that path. I also cannot determine from the client side what exactly schedules the consolidation runs; the volume (~20–75/day) does not correlate with new-session count (0–8/day here), so something other than session completion is driving the cadence.

   Context worth adding

   This installation deliberately uses persistent worker chat threads with context handoff between chats rather than Codex subagents, and some of those threads are very large (one rollout file is 183 MB; single turns carry ~820k input tokens). That may simply amplify what this issue reports — flagging it because the meta tracker mentions client-side workflow amplification.

   Workaround status

   The workaround already posted here ([memories] generate_memories = false, use_memories = true) was applied and reverted on this machine during unrelated testing, so I have no full-day before/after to contribute for it.

   Related tracker: #41220.