›_ Codex Issues
Codex Issues / #34070

Codex Windows App uses hardcoded %USERPROFILE%\.codex path — ignores CODEX_DIR / CODEX_HOME env vars

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

Feature Request

The Codex Windows App stores its user data (sessions, logs, memories, auth) in a hardcoded %USERPROFILE%\.codex directory and ignores the CODEX_DIR and CODEX_HOME environment variables that the Codex CLI tool respects.

Use Case

Users on Windows with limited C: drive space (e.g. small SSDs) or specific data organization requirements need to relocate the .codex data directory to another drive or path. Currently the only workaround is a directory symlink/junction, which is fragile and not officially supported.

Requested Behaviour

The Codex Windows App should read one of the following (in priority order) to determine where to store its user data:

  1. A CODEX_DIR or CODEX_HOME environment variable (matching the CLI tool behaviour)
  2. A config.toml setting (e.g. data_dir = "D:\Codex\data")
  3. Fall back to the current hardcoded %USERPROFILE%\.codex default

Why This Matters

  • Disk space management: ~/.codex can exceed 2 GB (session databases, logs, plugin caches)
  • Organisation: Users may keep all app data on a dedicated data drive
  • Consistency: The CLI tool already honours CODEX_DIR; the Windows App should too
  • Sync control: Users may want to exclude .codex from cloud backup on C: while keeping it on a local-only data drive

Workaround (not ideal)

Currently the only option is to manually create a directory junction/symlink:

mklink /D "%USERPROFILE%\.codex" "D:\path\to\.codex"

This requires Developer Mode or admin privileges and is unsupported by the app.

Environment

  • Windows App version: 26.715.3651.0
  • Windows 10 (local terminal, not WSL)
  • The Codex CLI tool (invoked via codex from terminal) does respect CODEX_DIR

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

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

  • #33635

Powered by Codex Action

xiaeducation9-maker · 1 month ago

Additional Windows Desktop failure case from a disk-cleanup attempt:

  • Codex Desktop build: 26.721.41059
  • Codex CLI: 0.145.0
  • Windows, native Desktop app
  • A user-level CODEX_HOME and CODEX_SQLITE_HOME were pointed at a copied alternate-drive directory to reduce C: usage.
  • The copied directory did not contain a fully consistent snapshot of all live authentication and SQLite state.
  • After the change, the user was unable to enter/use Codex normally for several hours and the app appeared disconnected from its expected login/local state.
  • Recovery was to remove both environment-variable overrides and return the live home to %USERPROFILE%\.codex. codex login status then reported Logged in using ChatGPT, and the active state database resumed writes under the default C: path.

This suggests relocation needs to be treated as an atomic, app-aware operation rather than a cache move. It would help if Desktop either:

  1. officially supported a single storage-location setting with atomic migration and validation, or
  2. rejected/warned about an incomplete alternate CODEX_HOME, clearly showing the active home path and offering a safe rollback.

Until then, moving the live home is not a safe disk-cleanup workaround. Only inactive session payloads should be archived, with authentication/configuration/live SQLite state kept in the default home.

tidytorch · 22 days ago

There is also an important multi-installation use case for this request.

On Windows, users may have both the stable ChatGPT/Codex desktop app and the beta app installed under the same Windows user account. These are useful as two independently configured clients: for example, stable connected to a WSL2 development environment and beta connected to the Windows-native environment.

At the moment, both app variants share %USERPROFILE%\\.codex, including config.toml and desktop state. As a result, changing the Agent Environment in one app changes the effective environment of the other app as well. This prevents users from running the two builds concurrently with different environments.

Please consider supporting an explicit per-app Codex home, for example:

  • Stable app: %USERPROFILE%\\.codex
  • Beta app: %USERPROFILE%\\.codex-beta

This could be implemented through an app-specific setting, a supported CODEX_HOME override honored by the desktop app, or another stable profile mechanism. The isolated root should cover configuration, auth, sessions, skills/plugins, caches, and SQLite state, with a safe first-run migration/copy flow.

This is not a request to use two Windows accounts. The goal is to keep both app variants usable at the same time under one Windows account, with one fixed to WSL and the other fixed to Windows native. If per-app isolation is not desired long-term, a single-app per-project Remote-WSL model would solve the underlying workflow problem; until then, isolated app roots would be a practical fallback.

boombx403-byte · 9 days ago

Hi @CTCycle, cross-platform WSL/Windows path mismatches often make healthy transcripts look broken when workspace contexts change. Codex Rescue Alpha5 explicitly separates transcript integrity from workspace path-family portability without rewriting saved paths.

If you'd like to check the local rollout safely:

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

Please sanitize private paths before posting any output.