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.
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗