Windows: Codex may create a literal %SystemDrive% directory in cwd when resolving ProgramData/default cache path

Resolved 💬 2 comments Opened Apr 7, 2026 by whale7788 Closed Apr 7, 2026

What version of Codex CLI is running?

@openai/codex 0.118.0 on Windows

What subscription do you have?

ChatGPT Plus

Which model were you using?

gpt-5.4

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What terminal emulator and version are you using (if applicable)?

PowerShell on Windows

What issue are you seeing?

Running codex creates a literal %SystemDrive% directory in the current working directory.

Example path created:

```text
D:\project\rt-offline-workorder\%SystemDrive%\ProgramData\Microsoft\Windows\Caches\

Files created there include:

  • cversions.2.db
  • {GUID}.2.ver0x0000000000000001.db

This looks like Windows cache/config data being written to a fallback path where %SystemDrive% was not expanded, instead of a real path such as:

C:\ProgramData\Microsoft\Windows\Caches\

My interactive PowerShell environment has the expected values:

$env:SYSTEMDRIVE
C:

$env:SYSTEMROOT
C:\Windows

$env:PROGRAMDATA
C:\ProgramData

$env:APPDATA
C:\Users\admin\AppData\Roaming

$env:LOCALAPPDATA
C:\Users\admin\AppData\Local

$env:USERPROFILE
C:\Users\admin

So this does not appear to be a normal shell environment issue on the machine itself.

What steps can reproduce the bug?

```markdown

  1. Open PowerShell in any repo or normal working directory.
  2. Run codex.
  3. After Codex starts, inspect the current directory.
  4. Observe that a literal %SystemDrive% directory may be created under the current working directory.

Example:

```text
<cwd>\%SystemDrive%\ProgramData\Microsoft\Windows\Caches\

In my case this happened under:

D:\project\rt-offline-workorder\%SystemDrive%\ProgramData\Microsoft\Windows\Caches\

The generated files included:

  • cversions.2.db
  • {GUID}.2.ver0x0000000000000001.db

I have not identified a special prompt or thread action that is required beyond starting codex.

What is the expected behavior?

  Codex should not create a literal `%SystemDrive%` directory in the working directory.

  If Windows known-folder resolution or fallback path resolution fails, Codex should either:

  - resolve to a real absolute Windows path such as `C:\ProgramData\...`, or
  - fail safely without writing cache/config files into the current working directory.

### Additional information

I saw issue #4180 and the collaborator comment saying the missing environment variables are now preserved.

  This seems different from that issue.

  Issue #4180 appears to be about missing environment variables when launching child processes / MCP servers.

  This issue appears to be in Codex's own Windows startup path handling, because the installed Windows binary still appears to reference ProgramData resolution /
  fallback behavior.

View original on GitHub ↗

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