Hidden memory_consolidation subagent consumed 5-hour Pro quota after Stop hook failure

Open 💬 3 comments Opened May 10, 2026 by Remedy92
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Title: Hidden memory_consolidation subagent consumed 5-hour Pro quota after Stop hook failure

What version of Codex is running?

Codex CLI: 0.130.0

Telemetry from the affected request reports Codex Desktop app version: 0.130.0-alpha.5

What subscription do you have?

ChatGPT Pro / Codex Pro

What issue are you seeing?

A hidden/background memory_consolidation subagent consumed my Codex 5-hour usage window even though I did not start a visible Codex chat at that time.

The local Codex logs show:

  • x-openai-subagent: memory_consolidation
  • thread_source: memory_consolidation
  • originator: Codex_Desktop
  • auth_mode: Chatgpt
  • model: gpt-5.4
  • reasoning_effort: medium
  • cwd: ~/.codex/memories

The input was not a user prompt. It was a hook failure:

<hook_prompt hook_run_id="stop:1:/Users/.../Projects/Revelar/.codex/config.toml">
/Applications/Xcode.app/Contents/Developer/usr/bin/python3: can't open file
'/Users/.../.codex/memories/.codex/hooks/semantic_heuristic_guard.py':
[Errno 2] No such file or directory
</hook_prompt>

The hidden assistant response in the websocket event was:

Still the same hook prompt. No new information.

If you want me to continue, paste one actual Terminal output from outside Codex:
...

This response was never visible as a normal chat. The thread did not show up as a regular archived session; it was only visible in ~/.codex/logs_2.sqlite.

The backend then returned:

type: usage_limit_reached
status_code: 429
X-Codex-Active-Limit: premium
X-Codex-Plan-Type: pro
X-Codex-Primary-Used-Percent: 100
X-Codex-Secondary-Used-Percent: 81
X-Codex-Primary-Window-Minutes: 300
X-Codex-Secondary-Window-Minutes: 10080

The local token telemetry also logged:

post sampling token usage:
total_usage_tokens=575428
estimated_token_count=Some(627651)
token_limit_reached=true

And another turn usage line:

codex.turn.token_usage.input_tokens=668017079
codex.turn.token_usage.cached_input_tokens=664668928
codex.turn.token_usage.non_cached_input_tokens=3348151
codex.turn.token_usage.output_tokens=303059
codex.turn.token_usage.reasoning_output_tokens=15218
codex.turn.token_usage.total_tokens=668320138
skipping active goal continuation for ephemeral thread

Expected behavior

Hidden/background memory consolidation should not silently exhaust the same user-facing 5-hour quota as intentional visible Codex work.

At minimum:

  • Background memory-consolidation usage should be visible in the usage UI/logs.
  • Stop hook failures inside a hidden consolidation worker should not create repeated or expensive model turns.
  • Project hooks should not be inherited into global memory-consolidation workers unless they are safely scoped to that worker.
  • If hidden memory workers count against paid usage, the user should be able to disable, bound, or inspect them clearly.

Actual behavior

A hidden memory_consolidation subagent appears to have run from the memory workspace, processed a Stop hook failure as model input, and hit the Pro 5-hour usage limit.

The incident is especially confusing because there was no visible user chat at the time.

Probable mechanism

The project had this Stop hook:

[features]
codex_hooks = true

[[hooks.Stop]]
[[hooks.Stop.hooks]]
type = "command"
command = '/usr/bin/python3 "$(git rev-parse --show-toplevel)/.codex/hooks/semantic_heuristic_guard.py"'
timeout = 10

During memory consolidation, the worker cwd was ~/.codex/memories, which is itself a git repo. Therefore:

git rev-parse --show-toplevel

resolved to ~/.codex/memories, causing the hook path to become:

~/.codex/memories/.codex/hooks/semantic_heuristic_guard.py

That file did not exist. The resulting hook error was then fed into a hidden memory-consolidation model turn.

This matches the current source shape:

  • codex-rs/memories/README.md says the memory pipeline runs asynchronously in the background, and Phase 2 spawns an internal consolidation sub-agent when the memory workspace changes.
  • codex-rs/memories/write/src/start.rs skips memory startup for non-root agents, then runs Phase 1 and Phase 2 asynchronously.
  • codex-rs/memories/write/src/phase2.rs sets the consolidation agent cwd to the memory root, makes it ephemeral, disables memory/collab/plugins/apps, and runs with no approvals/no network.
  • codex-rs/memories/write/src/runtime.rs starts the thread with SessionSource::Internal(InternalSessionSource::MemoryConsolidation) and ThreadSource::MemoryConsolidation.
  • codex-rs/core/src/client.rs maps MemoryConsolidation to x-openai-subagent: memory_consolidation.
  • codex-rs/core/src/session/turn.rs runs Stop hooks after the model response and, if the Stop hook blocks with continuation fragments, records a hook prompt and continues the turn.

Source inspected at openai/codex commit:

178c3d30053ba63d118ee93a0dbe2716a12e5769

Why this matters

This creates a real paid-usage safety issue:

  • The user did not intentionally start this model run.
  • The model run was hidden/ephemeral and not discoverable in normal chat history.
  • It consumed enough to hit the 5-hour Pro usage limit.
  • The trigger was an internal memory worker plus hook path-resolution failure.
  • The resulting quota loss is indistinguishable from user-initiated work in the usage UI.

Related reports

  • #19585: Pro weekly usage depletion and context/compaction usage waste.
  • #17496: memory cwd scoping concerns.
  • #18318: context compression usage spikes.
  • openai/codex-plugin-cc#102: need clearer Codex usage/rate-limit reporting.

Requested fix

Please investigate and consider:

  • Do not run project Stop/AfterAgent hooks inside internal memory-consolidation workers, or run only hooks from the memory worker's own trusted config.
  • Do not treat hook failures from hidden memory workers as user-visible continuation prompts that cause more model turns.
  • Surface hidden memory_consolidation usage in the usage UI/logs.
  • Add a setting to disable or strictly cap background memory-consolidation usage.
  • If background memory usage counts against Pro quota, document that clearly and expose exact per-run accounting.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 3 months ago

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

  • #21966

Powered by Codex Action

Mahkhmood9 · 3 months ago

Go the chat , with /resume please use the /feedback
(which also raise the idea how can you moderate feedback logs with modified clients[modified codex - / logic] , in this case close source is better?)

  1. https://developers.openai.com/codex/hooks#stop

""Citation matcher isn’t currently used for this event.""

<img width="200" height="200" alt="Image" src="https://github.com/user-attachments/assets/96c0a008-7035-47bc-b51a-5494b4010484" />

--

Wether the issue you raise is valid or not, make sure you vebarly express , like quota over spend

Chronicle uses the same model as your other Memories
e.g if 5.5 is used ... it would use the heavy 5.5 model , along side 175k token window

... speaking of Token / text embeding / text summerization , decompressing the embeded text ,,, into historical context of previous chats... and for example having more tokens is cheaper, but the same way we dont build human language like post-compressed tar/zip text and 60% text saving.. but morally its an expirement you must make, when talking computers and science ?

And Chronicle works by running sandboxed agents in the background to generate memories

refrencing (https://developers.openai.com/codex/memories/chronicle#which-model-is-used-for-generating-the-chronicle-memories)

<img width="1205" height="244" alt="Image" src="https://github.com/user-attachments/assets/b9237dcf-49f0-44ce-9db3-3f9c26686158" />

----
Unrelated taught
[output] Maybe another test , in the PR phase , for such failures? If this is an interduced bug , the user mention he is using 0.130.0-alpha.5...
[User intention] a kill switch, using a git command? [[hooks.Stop.hooks]] https://developers.openai.com/codex/hooks#stop
[user-result] Improper configratuion , and misinterputtion on the user behalf? And the user doesnt know how to properly set the Behavior he wish to achhieve, beliving it was running

It interesting , how summerizeing chat / and logic -- require a front tier model
Have you made an modification , to codex / and sublibariries ,

the design is sensetive, I managed to break codex like 20 times and I tweak it
But I am not getting younger I guess I am 65 at this point .

all of it is very sensetive , like modifiing https://github.com/openai/codex/blob/main/codex-rs/memories/write/templates/memories/stage_one_input.md?plain=1
the slightst

causes the model to go chimpanzee-crazy , alltho in my opionion it improved a lot

Remedy92 · 3 months ago

Thanks. Agree the hook failure is part of the trigger chain, but I think the product bug is narrower:

A hidden memory_consolidation / Chronicle background agent hit the 5h Pro quota without a visible chat or clear usage log entry. The local telemetry shows x-openai-subagent: memory_consolidation, thread_source: memory_consolidation, and the backend returned X-Codex-Primary-Used-Percent: 100.

So the ask is not “hooks should never fail”; it is: internal/background memory agents should be visible, quota-isolated, or hard-stopped when a hook failure creates a continuation loop.