Repository navigation
Hidden memory_consolidation subagent consumed 5-hour Pro quota after Stop hook failure #22008
Description
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_consolidationthread_source: memory_consolidationoriginator: Codex_Desktopauth_mode: Chatgptmodel: gpt-5.4reasoning_effort: mediumcwd: ~/.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 = 10During memory consolidation, the worker cwd was ~/.codex/memories, which is itself a git repo. Therefore:
git rev-parse --show-toplevelresolved 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.mdsays 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.rsskips memory startup for non-root agents, then runs Phase 1 and Phase 2 asynchronously.codex-rs/memories/write/src/phase2.rssets 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.rsstarts the thread withSessionSource::Internal(InternalSessionSource::MemoryConsolidation)andThreadSource::MemoryConsolidation.codex-rs/core/src/client.rsmapsMemoryConsolidationtox-openai-subagent: memory_consolidation.codex-rs/core/src/session/turn.rsruns 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
- Pro weekly usage limit depletes unusually fast on 5.5, worsened by unstable context compaction #19585: Pro weekly usage depletion and context/compaction usage waste.
- Memory read path ignores cwd and injects entire global memory_summary.md into initial context for new sessions #17496: memory cwd scoping concerns.
- Inefficient context compression #18318: context compression usage spikes.
- Add
/codex:usagecommand to show rate limits and usage 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_consolidationusage 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.
Activity
github-actions commentedon May 10, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Mahkhmood9 commentedon May 10, 2026
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?)
""Citation matcher isn’t currently used for this event.""
--
1.
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)
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 commentedon May 10, 2026
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 showsx-openai-subagent: memory_consolidation,thread_source: memory_consolidation, and the backend returnedX-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.