Windows Codex app/CLI leave duplicated executables, opaque runtime paths, and sensitive local state without cleanup/uninstall controls

Open 💬 6 comments Opened Jun 9, 2026 by Aesthermortis
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

  1. Multiple Codex executables exist across app, standalone CLI, and package cache paths.
  2. Multiple runtime tools exist across paths, including node.exe, rg.exe, command runners, and sandbox helpers.
  3. The app and CLI appear to share %USERPROFILE%\.codex state but not a single runtime/binary source.
  4. The standalone installer has an install path but no clearly documented uninstall path.
  5. App uninstall did not fully clean local runtime/state/cache data.
  6. .codex accumulates sessions, logs, SQLite state, attachments, plugin caches, skills, and browser/tooling cache.
  7. There is no visible retention policy or cleanup command for local sensitive state.
  8. Large local log/state files can accumulate.
  9. 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:

  1. A documented uninstall command for the standalone CLI installed via install.ps1.
  2. A cleanup command, for example:
codex cleanup
codex cleanup --cache
codex cleanup --sessions
codex cleanup --logs
codex cleanup --state
codex cleanup --all-local-data
  1. A retention policy for:
sessions/*.jsonl
logs*.sqlite*
state*.sqlite*
cache/*
plugins/cache/*
attachments/*
computer-use/*
packages/standalone/*
  1. A clear separation between:
  • durable config
  • auth
  • user memories
  • session history
  • cache
  • executable/runtime packages
  • logs
  • sandbox helper binaries
  1. A single authoritative runtime path used by both app and CLI, or a clearly documented separation if they are intentionally independent.
  1. A UI option in the app to delete:
  • session history
  • local logs
  • local cache
  • attachments
  • tool/browser/computer-use state
  • all local Codex data
  1. 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.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #26962
  • #26366
  • #25876
  • #26011
  • #26374

Powered by Codex Action

Aesthermortis · 2 months ago

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:

Archive / hide from main view
Delete conversation from visible history
Permanently purge local data
Permanently purge synced/cloud data, if applicable
Delete local tool/session/cache artifacts
Delete attachments and generated files

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:

Archive
Delete
Delete permanently
Delete local data
Delete all local Codex data
Delete all chats/history
Delete all tool/session/cache data

Each action should explain what it affects:

Visible UI history
Local session files
SQLite state/logs
Attachments
Tool outputs
Plugin/browser/computer-use state
Synced account data

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.

Aesthermortis · 2 months ago
Potential duplicates detected. Please review them and close your issue if it is a duplicate. Codex App fails to start on Windows after reinstall due to stale marketplace entries in config.toml #26962 Windows Desktop 26.601: global CLI and Desktop bundled-plugin reconcile can fight over shared config.toml #26366 Windows sandbox fails with standalone CLI despite valid junction install layout #25876 config.toml MCP paths stale after auto-update — node_repl fails with 'os error 3' #26011 * app-server: feedback log sqlite (logs_N.sqlite) grows unbounded — ~0.75 GB/day, no retention/rotation #26374 _Powered by Codex Action_

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:

  • stale marketplace/config entries after reinstall
  • Desktop and global CLI fighting over shared config.toml
  • Windows sandbox failures with standalone CLI
  • stale MCP paths after auto-update
  • unbounded logs_N.sqlite growth

This 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:

  • a documented standalone CLI uninstall path
  • app uninstall that removes app-owned runtime/cache files
  • explicit local data cleanup controls
  • retention/rotation for logs and session files
  • clear separation between config, auth, memories, sessions, logs, cache, plugin data, and executable/runtime packages
  • direct deletion/purge semantics, not only archive/hide behavior

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.

Necmttn · 2 months ago

Codex needs a local-state inventory before uninstall or cleanup can be safe.

A codex doctor storage style 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._

boombx403-byte · 9 days ago

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:

pip install codex-rescue==0.1.0a5
codex-rescue doctor --latest

No raw data is needed; please redact any private repository paths before sharing results.

Aesthermortis · 9 days ago

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.