Codex desktop should separate user deliverables from Codex system files

Resolved 💬 2 comments Opened May 4, 2026 by sapodaca58 Closed Jul 1, 2026

What variant of Codex are you using?

Desktop app on Mac

What feature would you like to see?

Codex team,

Codex desktop needs a cleaner local file architecture for non-developer professional users.

The current experience makes it too easy for Codex-related working files, scripts, caches, generated artifacts, logs, OCR residue, and other system material to appear in or near user work folders. That creates confusion and storage clutter, especially for users working in local filesystem. Over time it eats up large chunks of storage. SSD storage is expensive nowadays

A simpler model would be better:

The user designates a folder for deliverables.
Only user-facing deliverables are saved there.
Codex system files, scratch files, scripts, caches, OCR intermediates, temporary artifacts, and logs stay inside Codex-owned storage.
Codex internally indexes those system files to the relevant project, session, and deliverables folder.
The user does not need to see or manage Codex junk during ordinary work.
Then Codex should run a periodic cleanup process.

That cleanup process should present a simple user-friendly interface showing items Codex believes are safe to remove, such as stale caches, temporary files, old session files, generated intermediates, logs, and abandoned workspaces. The user can review, approve, archive, or delete them.

The key point: users should not have to understand .py, .pyc, cache folders, OCR intermediates, lock files, build artifacts, or hidden app state. Codex should manage its own working debris.

Final deliverables belong in the folder the user chooses. Codex machinery belongs in Codex-controlled storage. Cleanup should be periodic, transparent, and user-approved.

This would make Codex feel much more trustworthy for business users using it for real client work.

Additional information

_No response_

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗