Windows Codex app/CLI leave duplicated executables, opaque runtime paths, and sensitive local state without cleanup/uninstall controls
Summary
On Windows, Codex currently appears to spread runtime binaries, package caches, sandbox helpers, logs, session history, plugin caches, SQLite state, and app metadata across multiple locations. This makes it hard to reason about which executable/runtime is active, hard to fully uninstall, and risky from a local privacy/data-retention perspective.
The current behavior creates a split-brain installation model:
- Codex app runtime under
%LOCALAPPDATA%\OpenAI\Codex - Codex standalone CLI command under
%LOCALAPPDATA%\Programs\OpenAI\Codex - Standalone package cache under
%USERPROFILE%\.codex\packages\standalone - Shared state, auth, sessions, logs, memories, plugins, skills, attachments, SQLite files, and app metadata under
%USERPROFILE%\.codex
This violates the principle of a single source of truth for a local developer tool.
Environment
- OS: Windows
- Codex CLI version observed:
0.138.0 - Install methods used:
- Codex Windows app
- Standalone CLI installer via
install.ps1 - Previous npm global install, later removed
- Shell: PowerShell
Evidence
After removing the npm global package, where.exe codex showed the standalone CLI command at:
%LOCALAPPDATA%\Programs\OpenAI\Codex\bin\codex.exe
That executable targeted a release payload under:
%USERPROFILE%\.codex\packages\standalone\releases\0.138.0-x86_64-pc-windows-msvc\bin\codex.exe
The standalone package directory also used:
%USERPROFILE%\.codex\packages\standalone\current
%USERPROFILE%\.codex\packages\standalone\releases
%USERPROFILE%\.codex\packages\standalone\install.lock
Separately, the Codex app installed or retained binaries under:
%LOCALAPPDATA%\OpenAI\Codex\bin
including duplicated runtime-like files such as:
codex.exe
codex-command-runner.exe
codex-windows-sandbox-setup.exe
node.exe
node_repl.exe
rg.exe
After uninstalling the app, local folders and/or Codex state remained and required manual deletion.
Local state retained under .codex
The following data remained under %USERPROFILE%\.codex:
sessions/
attachments/
cache/
computer-use/
computer-use-turn-ended/
memories/
plugins/
process_manager/
skills/
sqlite/
vendor_imports/
.codex-global-state.json
auth.json
history.jsonl
logs_2.sqlite*
state_5.sqlite*
goals_1.sqlite*
memories_1.sqlite*
session_index.jsonl
models_cache.json
chrome-native-hosts*.json
Some of these files can contain sensitive information such as:
- prompts
- command history
- file paths
- repository names
- snippets of source code
- attachments
- browser/plugin metadata
- local state
- memory/state data
- authentication/session material
There is no obvious user-facing cleanup flow for this data.
Observed problems
- Multiple Codex executables exist across app, standalone CLI, and package cache paths.
- Multiple runtime tools exist across paths, including
node.exe,rg.exe, command runners, and sandbox helpers. - The app and CLI appear to share
%USERPROFILE%\.codexstate but not a single runtime/binary source. - The standalone installer has an install path but no clearly documented uninstall path.
- App uninstall did not fully clean local runtime/state/cache data.
.codexaccumulates sessions, logs, SQLite state, attachments, plugin caches, skills, and browser/tooling cache.- There is no visible retention policy or cleanup command for local sensitive state.
- Large local log/state files can accumulate.
- Windows sandbox errors become hard to diagnose because it is unclear which runtime/helper path is authoritative.
Expected behavior
Codex on Windows should have a single coherent installation layout.
Recommended model:
%LOCALAPPDATA%\OpenAI\Codex
├─ bin
├─ runtime
├─ sandbox
├─ cache
├─ logs
├─ state
└─ config
or, if %USERPROFILE%\.codex remains the canonical user state root, runtime binaries should not be placed there. .codex should not mix durable user config with large executable caches, plugin caches, sessions, attachments, logs, and opaque SQLite state without cleanup controls.
Requested changes
Please add:
- A documented uninstall command for the standalone CLI installed via
install.ps1. - A cleanup command, for example:
codex cleanup
codex cleanup --cache
codex cleanup --sessions
codex cleanup --logs
codex cleanup --state
codex cleanup --all-local-data
- A retention policy for:
sessions/*.jsonl
logs*.sqlite*
state*.sqlite*
cache/*
plugins/cache/*
attachments/*
computer-use/*
packages/standalone/*
- A clear separation between:
- durable config
- auth
- user memories
- session history
- cache
- executable/runtime packages
- logs
- sandbox helper binaries
- A single authoritative runtime path used by both app and CLI, or a clearly documented separation if they are intentionally independent.
- A UI option in the app to delete:
- session history
- local logs
- local cache
- attachments
- tool/browser/computer-use state
- all local Codex data
- Documentation explaining exactly which paths are created by:
- Windows app
- standalone CLI installer
- npm global install
- IDE extension
- plugins/skills/browser tools
Why this matters
Codex reads repositories, runs shell commands, stores session traces, records tool state, and may keep local snippets, paths, attachments, logs, and SQLite state. This is sensitive local developer data.
A developer tool should not require manual forensic cleanup across multiple hidden folders after uninstall. App, CLI, sandbox, and runtime binaries should be predictable, deduplicated, and documented.
6 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Related UX problem: archive is not deletion
This problem is part of a broader cleanup/data-retention issue in Codex and ChatGPT-style local tooling: archiving is not deletion.
Users need explicit, separate actions for:
The current archive-first model is confusing and weak from a privacy perspective. Archiving should only mean “hide from active view.” It should not be treated as a deletion workflow, and users should not have to archive something first before deleting it.
A good implementation should expose clear actions:
Each action should explain what it affects:
For developer tooling, this is especially important because sessions can include repository paths, source snippets, shell commands, file contents, attachments, generated patches, terminal output, and private project context.
Archiving this data is not enough. Users need a direct and auditable way to remove it.
The duplicate suggestions actually seem to confirm that this is not one isolated bug, but a systemic Windows layout/state-management problem.
The related issues appear to cover separate symptoms:
config.tomllogs_N.sqlitegrowthThis issue is intended as the umbrella/root-cause request: Codex on Windows needs a clear single-source-of-truth model for app, CLI, runtime binaries, sandbox helpers, logs, sessions, local state, cache, and cleanup.
Even if some symptoms are tracked elsewhere, users still need:
Archiving is not deletion. For a developer tool that stores commands, repository paths, file snippets, attachments, tool output, and local state, users need a visible way to delete and purge local data without manually inspecting hidden folders.
Codex needs a local-state inventory before uninstall or cleanup can be safe.
A
codex doctor storagestyle view could list executable paths, package caches, config roots, session/log DBs, plugin/skill directories, auth material, and data-retention class. Cleanup can then offer separate actions for uninstall binaries, archive sessions, delete local transcripts, and revoke auth.---
_Generated with ax._
Hi @Aesthermortis, I'm testing a local-first, read-only diagnostic tool (Codex Rescue Alpha5) against local session persistence and rollout anomalies. It evaluates schema compatibility, tool correlation, and state consistency without modifying the original rollout or SQLite databases.
If the affected session is still present locally, you can run:
No raw data is needed; please redact any private repository paths before sharing results.
Thanks for the suggestion. I don't think running Codex Rescue is appropriate for this issue.
#27230 is not primarily about diagnosing a damaged individual session or identifying rollout/projection anomalies. It is about the architectural ownership of Codex's Windows installation and local state: multiple runtime locations, duplicated executables, unclear authority between app and CLI, retention, uninstall behavior, and cleanup boundaries.
A third-party diagnostic may help inspect symptoms produced after that architecture has already created ambiguous state, but it does not address the underlying problem. In fact, requiring an external forensic tool to determine which runtime/state is authoritative would itself be evidence that the ownership model is insufficiently explicit.
The expected direction here is a coherent SSOT/DRY model where runtime authority, state ownership, retention classes, and cleanup/uninstall responsibilities are deterministic and documented by Codex itself.
So I would prefer to keep session/projection diagnostics separate unless they provide direct evidence about those installation/runtime/state ownership boundaries.