Unexpected background task spawning and severe usage drain in VS Code Codex extension #18358

What issue are you seeing?

In the VS Code Codex extension, a normal user task appears to trigger additional background tasks or subagent sessions that I did not explicitly start.

The main problem does not appear to be that the original prompt itself is unusually expensive. Instead, the original task completes, and then separate background work starts afterward and consumes a large amount of usage.

Based on the local rollout evidence, this background activity appears to be related to internal memory handling or memory consolidation work.

What steps can reproduce the bug?

1. Open VS Code and the Codex extension.
2. Start a new chat or thread.
3. Send a normal prompt.
4. Wait for the main response to complete.
5. Observe that usage may continue increasing afterward.
6. Inspect local rollout or session artifacts.

In my case, after the main task completed, separate background sessions were created under ~/.codex/memories, including sessions with source.subagent="memory_consolidation".

What is the expected behavior?

A normal user task should only run the work directly associated with that task, unless the product clearly indicates that additional background work is being started.

If Codex starts background tasks automatically, the IDE should clearly show:

• that those tasks were started
• what they are
• whether they are still running
• how much usage they are consuming

Hidden or unclear background tasks should not be able to drain most of the user's usage.

Additional information

I collected local rollout evidence showing that:

• the original user task completed normally
• separate background sessions were started afterward
• at least one of those background sessions ran much longer and consumed substantially more usage
• one of those background sessions ended with a sandbox policy mismatch error

Because of this behavior, a small number of normal user interactions can end up consuming most or all of the available usage limit.

The usage drain appears to be a consequence of unexpected background task spawning, rather than the direct cost of the visible user prompt alone.