[Windows] Image tool retains stale generations and amplifies one workflow into multi-GB local state

What version of the Codex App are you using (From “About Codex” dialog)?

Codex App 26.810.4967.0

What subscription do you have?

Pro

What platform is your computer?

Windows Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary

During a long-running workflow that used Codex's built-in image-generation tool, Codex retained superseded and rejected image generations and accumulated extremely large thread state. The problem was not limited to the image cache: image-heavy history was also persisted across the parent task, repeated context compactions, and spawned-agent rollouts.

One logical workflow produced:

• 15 rollout JSONL files totaling approximately 9.36 GB
• One parent rollout of approximately 2.58 GB
• Several child-agent rollouts of approximately 1.2 GB each
• 86 files under the task-specific generated_images directory totaling approximately 172 MB

The App became progressively slower and unreliable. During the same period, local logs recorded 31 net::ERR_INSUFFICIENT_RESOURCES failures, 7 fatal out-of-memory allocation failures, 55 HTTP 5xx responses, and 1,349 file-watch errors. These errors are presented as correlated symptoms; I have not proven that every one was caused by the same storage amplification.

Archiving the task did not reclaim the task-specific rollout or generated-image storage. Recovering the space required manual cleanup of the task records, rollout files, generated-image directory, and associated local log rows.

This report intentionally omits the underlying project, task objective, prompts, image contents, local paths, and session identifiers.

What steps can reproduce the bug?

1. Start a Codex App task that repeatedly uses the built-in image-generation and image-editing tool.
2. Generate multiple iterations, including versions that are rejected, superseded, or replaced by later generations.
3. Continue the same task long enough for context compaction to occur.
4. Spawn several child agents from the image-heavy parent task.
5. Continue generating and evaluating images in the parent and/or child tasks.
6. Inspect the task's local rollout files and $CODEX_HOME/generated_images/<thread-id>/.
7. Observe that old intermediate image files remain and that parent history is materialized into large child rollout files.
8. Archive the task and compare storage usage before and after.

This is an observed production workflow rather than a minimal deterministic reproducer. No raw rollout or session ID is included because those records contain private task content.

What is the expected behavior?

• Rejected or superseded image generations should have a documented retention policy and should be safely pruned or deduplicated.
• Generated image bytes and large image-tool payloads should be stored once using content-addressed or otherwise shared storage, then referenced from transcripts.
• Context compaction should not repeatedly serialize historical image payloads.
• Spawned agents should use references or bounded handoffs instead of duplicating a multi-gigabyte parent history.
• The App should expose per-task and global storage usage, quotas, retention controls, and warnings before state reaches multi-gigabyte size.
• Archiving or deleting a task should clearly and reliably reclaim its task-specific generated images, rollouts, and associated local state.
• A selected final image should be distinguishable from disposable intermediate generations.

Additional information

Impact

High. A single image-heavy workflow consumed roughly 9.5 GB of task-specific local storage, degraded UI responsiveness, and coincided with browser/app resource exhaustion and out-of-memory failures. The cleanup path was not discoverable or safe through the App UI.

Related reports

• #35458 reports screenshot payloads being re-persisted during compaction and inherited by subagent forks.
• #38038 requests lifecycle controls for the generated_images cache.

This case appears related but is distinct in two ways: it was observed on the Windows Codex App with the built-in image-generation workflow, and it combined stale generated-image retention with multi-gigabyte rollout amplification and severe runtime failures.

Suggested safeguards

• Content-addressed storage for generated images and image-tool outputs
• Reference counting and garbage collection for superseded generations
• Delta/reference-based child-agent rollouts
• Automatic pruning after the user selects a final generation
• Per-task storage metrics, configurable retention, and hard safety limits
• A supported "delete task and all local artifacts" operation

I can provide additional privacy-safe structural statistics if useful, but I will not upload raw rollouts or generated images because they contain private project content.