On Windows codex doesn't respect path and always launches tasks at `C:\`
Open 💬 5 comments Opened Jan 22, 2026 by benaadams
💡 Likely answer: A maintainer (etraut-openai, contributor)
responded on this thread — see the highlighted reply below.
What version of Codex is running?
codex-cli 0.87.0
What subscription do you have?
Pro
Which model were you using?
gpt-5.2-codex
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What terminal emulator and version are you using (if applicable)?
Windows Terminal (PowerShell)
What issue are you seeing?
Every time codex launches a CLI task it reverts to starting in C:\ rather than the current working directory e.g. D:\Github\Something
This means each command must either be prefixed with a change directory (e.g. Set-Location) or use full absolute paths
However this then messes up the permission requests
What steps can reproduce the bug?
Uploaded thread: 019be4e0-1772-7492
What is the expected behavior?
Starts in working directory and doesn't have to prefix every command with a change directory (and then more convoluted permission request)
Additional information
_No response_
5 Comments
Having the same issue. Causing Codex to ask permission and trying to elevate the process to admin continuously.
@paknudsen, if you haven't already done so, try enabling the experimental Windows sandbox. Without a sandbox, we need to be really conservative about which tool calls we allow without user permission.
@etraut-openai Thanks for following up! I am running in the sandbox. Codex CLI on Windows with sandbox was working very well for me until about v0.88 (if I recall correctly).
But my current thinking is that I might have screwed up my env. somehow by installing newer PowerShell versions in parallell with the old/builtin. Will Codex work differently/less effective in PowerShell 1.0 vs latest/7.5.4?
Also I am wondering if what I thought was a constant nag about elevating process is a runonce Sanbox setup that needs localadmin the first time it runs? Yesterday I gave it access once and it stopped nagging.
All that said WSL running works pretty well, except the filesystem is slow and moving repo into that filesystem does not work in our environmen (anti malware stalls wrecks havoc with perf).
Yes, the latest sandbox mechanism requires one-time elevation the first time it runs, so that explains what you were seeing.
Thanks for the quick reply! That's very helpful to understand. Then I just need to figure out why every single command requires "accept this function call" 😅