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
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

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 ↗

2 Comments

whale7788 · 4 months ago

Additional repro detail:

Inside the PowerShell environment launched from Codex, these variables were empty:

SYSTEMDRIVE=
PROGRAMDATA=
APPDATA=
LOCALAPPDATA=
USERPROFILE=

Only SYSTEMROOT was set:

SYSTEMROOT=C:\Windows

This differs from my normal interactive PowerShell session, where all of these variables are present.

etraut-openai contributor · 4 months ago

Thanks for the bug report. We'll share the feedback with the team responsible for training our codex models. If you see other model behavior that you'd like to report, please use the /feedback command. That will provide us with additional details including logs and conversation text.