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

Open 💬 4 comments Opened Jun 9, 2026 by Aesthermortis

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 ↗

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