Codex App: add lifecycle controls for the generated_images cache (usage, retention, open folder, and final export)

What variant of Codex are you using?

Codex App on macOS.

Version / environment

• Codex App: 26.803.41515 (bundle 6321)
• macOS: 27.0 (26A5378n)
• Architecture: Apple Silicon / arm64

What feature would you like to see?

Please add user-facing lifecycle controls for locally generated images stored under:

$CODEX_HOME/generated_images/<thread-id>/

The hidden location is reasonable for an internal cache. The problem is that the product currently does not clearly distinguish that temporary cache from user-owned final assets, and it does not provide a discoverable way to inspect or manage the cache.

On one real installation, the directory accumulated:

• 85 PNG files
• 24 thread directories
• 137 MB
• files dated from 2026-07-13 through 2026-08-12

The files use opaque thread and execution IDs rather than meaningful asset names. No byte-identical duplicates were found, so this measurement reflects normal accumulation across image-generation and editing work, including discarded iterations.

I could not find a setting or documented config.toml option for:

• viewing generated-image storage usage;
• opening the cache folder;
• configuring a retention period or storage quota;
• choosing a separate cache location;
• safely cleaning discarded generations;
• saving the selected final image to a visible project/workspace location with a meaningful filename.

Manual relocation or deletion is risky because older thread records can contain absolute paths to files under generated_images, so users cannot know whether cleanup will break historical image previews or later tool access.

The bundled imagegen skill already describes the intended semantic boundary: preview-only images may remain in the default $CODEX_HOME/generated_images path, while project-bound final assets should be moved or copied into the workspace. The App should make this boundary visible and manageable rather than relying entirely on prompt wording and manual filesystem work.

Source:
https://github.com/openai/codex/blob/main/codex-rs/skills/src/assets/samples/imagegen/SKILL.md

Suggested MVP

Add a Settings → Storage → Generated images section with:

1. Current size, file count, and oldest/newest item.
2. An Open Folder action.
3. Configurable retention, for example: manual only / 30 / 60 / 90 days / keep forever.
4. An optional storage quota and warning before the limit is reached.
5. Safe cleanup semantics that do not silently break thread previews. If previews depend on local absolute paths, show that dependency or preserve a content-addressed preview copy.
6. A Save final image to workspace… action with a meaningful filename, while treating unselected generations as cache.
7. Optionally, a configurable cache location for users who need generated data on another disk.

The default hidden cache can remain unchanged. The requested improvement is a visible lifecycle: temporary generation → selected final asset → safe cleanup.

Steps to observe the current behavior

1. Generate and edit images in several Codex App threads.
2. Inspect $CODEX_HOME/generated_images.
3. Observe per-thread folders with opaque generated filenames.
4. Search Codex App settings and config.toml for storage, location, retention, quota, or cleanup controls.
5. Observe that the cache continues to grow and manual cleanup has unclear consequences for old threads.

Related issues

• #28187 covers general local session retention and cleanup UX.
• #28209 asks to open local images externally or reveal their folder.
• #28848 and #28881 cover the opposite failure mode where generated images were not materialized; this request concerns lifecycle management when they are saved successfully.

Why this matters

This is both a storage-management and asset-management issue. Users should not need to reverse-engineer an internal directory to find final images, and they should not have to choose between unbounded growth and potentially breaking historical conversations.