Codex Desktop idle usage drain from background memory generation; stopped after generate_memories=false

[Allmight97]

Summary

Codex Desktop appears to consume 5-hour/weekly usage while idle (~2% every few moments) when background memory generation is enabled. Local logs show a real gpt-5.4 Responses sampling request running from the memory subsystem (cwd=~/.codex/memories) while I was not actively using Codex. After changing only generate_memories = false and reloading the app, the idle usage drain stopped in my observation window and no further sampling requests appeared in local logs.

This looks closely related to #19105 and possibly #19123, but I am opening a new issue because #19105 is closed and I have before/after local diagnostics that may help narrow the behavior.

Environment

• Product: Codex Desktop app
• App version: 26.422.30944
• Platform: macOS
• Plan: ChatGPT Pro
• Model observed in the background request: gpt-5.4

Relevant config before mitigation:

[features]
memories = true

[memories]
generate_memories = true
use_memories = true
max_rollouts_per_startup = 6
min_rollout_idle_hours = 12

Current mitigation:

[features]
memories = true

[memories]
generate_memories = false
use_memories = true
max_rollouts_per_startup = 6
min_rollout_idle_hours = 12

What happened

While Codex Desktop was open but idle, I watched my 5-hour limit continue dropping even though I was not initiating work in Codex.

Local logs showed a background model request from the memory subsystem during that period:

start_local: <redacted>
end_local:   <redacted, about 1.5 minutes later>
model:       gpt-5.4
cwd:         ~/.codex/memories
log context: run_sampling_request, responses_websocket, api.path="responses"

This appears to be an actual model sampling request, not UI polling or thread-list activity.

After setting generate_memories = false and reloading Codex Desktop, I checked local logs for new run_sampling_request / responses_websocket entries after reload and saw no new sampling requests during the idle observation window. My 5-hour limit also stopped dropping during that same window.

Local diagnostics used

I used queries like this against ~/.codex/logs_2.sqlite:

sqlite3 -readonly ~/.codex/logs_2.sqlite "
select
  datetime(min(ts),'unixepoch','localtime') start_local,
  datetime(max(ts),'unixepoch','localtime') end_local,
  count(*) log_rows,
  substr(feedback_log_body, instr(feedback_log_body,'model='), 20) model,
  substr(feedback_log_body, instr(feedback_log_body,'cwd='), 90) cwd
from logs
where feedback_log_body like '%run_sampling_request%'
group by model, cwd
order by min(ts);
"

And, after reload/mitigation, checked for new sampling requests after a cutoff timestamp:

sqlite3 -readonly ~/.codex/logs_2.sqlite "
select
  datetime(min(ts),'unixepoch','localtime') start_local,
  datetime(max(ts),'unixepoch','localtime') end_local,
  count(*) log_rows,
  substr(feedback_log_body, instr(feedback_log_body,'model='), 20) model,
  substr(feedback_log_body, instr(feedback_log_body,'cwd='), 90) cwd
from logs
where ts >= <cutoff_epoch>
  and feedback_log_body like '%run_sampling_request%'
group by model, cwd
order by min(ts);
"

Result after mitigation (generate_memories = false & restart codex app and app server): no rows during the idle observation window.

I can share more detailed sanitized log excerpts, state DB rows, timestamps, or thread/job IDs if useful.

Expected behavior (knowing this is experimental)

More generally, if memory generation is expected to consume significant usage, Codex should make that visible and controllable:

1. Show when background memory generation/consolidation is running.
2. Show the model/job type and estimated/actual usage impact if possible.
3. Document whether generate_memories = false is the intended way to preserve memory reads while disabling background memory writes.
4. Avoid silently consuming a meaningful amount of scarce 5-hour/weekly usage while the user is not actively using Codex.

Actual behavior

With memories = true, generate_memories = true, and use_memories = true, Codex Desktop appears to run background memory work from ~/.codex/memories using gpt-5.4, and the 5-hour limit can drop while the app appears idle.

Changing only generate_memories = false appears to stop the idle drain in my current observation window while keeping use_memories = true.

Why this matters

I understand that memory generation is experimental and consumes tokens. The problem is the control and visibility boundary: from the user perspective, Codex Desktop is idle, but 5-hour/weekly usage can still be consumed by background memory work. Which feels bad. That makes it hard to safely leave the app open unless background generation can be explicitly disabled while preserving memory reads.

I hope there's details in here that give someone an idea how to balance mem_gen - maybe use a more efficient model while still experimenting? At least now with generate_memories = false I don't have to worry and behavior seems to be normal again.

[github-actions]

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

• "Memories" consuming rate limit disproportionately #19105
• Unexpected background task spawning and severe usage drain in VS Code Codex extension #18358
• Codex Desktop: Enabling Memories causes disproportionate quota usage #18699
• Codex Desktop macOS consumes token quota while idle before any prompt, even after state reset and MCP disabled #19662

Powered by Codex Action

[jif-oai]

Thanks for the feedback. I'll have a look

[Allmight97]

Thanks for the feedback. I'll have a look

Update: I've had generate_memories = false since this was posted and it seems to have addressed the 'vampire drain' when codex is idle. However I noticed today (still with generate_memories = false) there's still token usage slowing going through rate limits but it's not consistent enough for me to give you more than that, and seems unrelated to generate_memories flag.

I have observed though that if I'm using gpt 5.5 through pi agent or opencode cli (using my other openai account that's not logged into codex app) I noticed (possibly) a hit on my usage as displayed in the codex app.

Is it possible that with the app running it is intercepting calls to openai and using my main account logged into the app instead of the account I'm authenticated in on Pi and opencode? I only use my main Pro account in codex App and only use my plus account on Pi and opencode.

[raymondgtayloriv-byte]

I am seeing what appears to be the same or a closely related idle quota-drain issue on Windows.

Codex App version:
26.422.3464.0

Subscription:
ChatGPT Plus

Platform:
Microsoft Windows NT 10.0.26200.0 x64

Install/version check:
winget list | Select-String -Pattern "Codex|OpenAI" returned:

Codex MSIX\OpenAI.Codex_26.422.3464.0_x64__... 26.422.3464.0

codex --version did not work, and Get-Command codex / where.exe codex did not return a CLI path, so this appears to be the desktop/MSIX app rather than a CLI install.

Settings/context:

• Memories had been enabled when I observed the drain.
• I turned off Enable Memories after seeing this issue and related reports.
• Codex dependencies are still enabled.
• I have not yet confirmed whether disabling Memories fully stops the drain over a longer observation window.

Observed behavior:
While the Codex desktop app appeared idle/completed, with no active streaming response and the composer showing “Ask for follow-up changes,” my visible rate-limit meter continued dropping.

I observed the 5-hour remaining percentage fall while I was not sending additional prompts:

• about 9%
• then about 7%
• then about 5%

Context:

• Project/repo: lumen-cartographer
• Branch shown in UI: main
• Mode shown in UI: Work locally
• Model shown in UI: GPT-5.5 High
• Access mode shown in UI: Full access
• The task output appeared complete; the UI showed file diffs and a recommended commit message.
• I did not click Commit or Undo.
• The app was left open on the completed task screen.
• Closing the Codex app was the only clear way I knew to stop the visible drain.

Expected behavior:
If no task is actively running and no follow-up has been sent, the 5-hour/weekly usage meters should not continue decreasing, or the app should clearly show what background job is consuming quota.

Actual behavior:
The visible 5-hour remaining percentage continued decreasing while the app appeared idle.

Screenshots:
Attached.

Notes:
I cannot confirm whether this is specifically background memory generation, usage-meter accounting, polling, dependency handling, or another background Codex process. I am adding this as Windows desktop-app evidence because the visible behavior matches idle quota drain.

[jif-oai]

Just to make things clear:
Memories are a token consuming product that run in the background so this is expected to see some token usage. But this token usage shouldn't be continous in idle mode of the app

I'm checking if there is anything that could be responsible of this token usage

[jif-oai]

#19970