Windows: Codex may create a literal %SystemDrive% directory in cwd when resolving ProgramData/default cache path
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
- Open PowerShell in any repo or normal working directory.
- Run
codex. - After Codex starts, inspect the current directory.
- 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.
2 Comments
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.
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
/feedbackcommand. That will provide us with additional details including logs and conversation text.