codex - 💡(How to fix) Fix Hidden memory_consolidation subagent consumed 5-hour Pro quota after Stop hook failure [3 comments, 3 participants]

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.