Windows Codex Desktop Local mode: agent commands run from C:\ while integrated terminal uses project directory

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

• #20725

Powered by Codex Action

I am seeing the same symptom in Codex Desktop on Windows: in a Local project thread, agent-run PowerShell commands start from C:\ instead of the selected project directory.

In my case, the issue occurs under Default permissions / native Windows sandbox. With Full access, Get-Location returns the correct project path.

I first reproduced this in an existing project located under Dropbox:

H:\Dropbox\_works\Codex\<project>

I then completely reinstalled Codex App and rebuilt the .codex directory from scratch, but the issue still reproduced.

To determine whether this was specific to my existing project, I created multiple empty projects at different paths on the same machine and asked the agent to run Get-Location.

Paths where the agent returned C:\:

H:\Dropbox\_works\Codex\test
H:\Dropbox\_Codex\CodexPathTestUnderBarDB

Paths where the agent returned the correct project directory:

H:\PathTest
H:\Codex\CodexPathTest
H:\Dropbox\CodexPathTestDB
H:\_Codex\CodexPathTestUnderBar
H:\Dropbox\DorpBox_CodexPathTest

In this environment, the failure appears to be triggered by projects located under the actual Dropbox-synced folder where a Dropbox-relative path segment begins with _.

I do not know whether the original reporter is also using Dropbox or another cloud-synced folder, so this may not be the same root cause. However, it seems potentially relevant because the visible symptom is identical: the project is opened correctly in the app, but the agent-run command environment falls back to C:\.

Additional observations:

• This reproduces after a clean Codex App reinstall and fresh .codex state.
• The issue occurs with Default permissions, but not with Full access.
• Explicitly adding the real project path as a project-local writable_roots entry makes access to that project possible without approval, but does not correct the initial Get-Location result.
• C:\ does not appear to become broadly writable in my testing, so this may be a workspace/cwd handoff or sandbox writable-root registration problem rather than a complete sandbox bypass.

Just to add another data point: I’m hitting what looks like the same issue on Windows.

My project is opened in Codex Desktop Local mode under:

D:\47065\Documents\wasm-optimization

But when the agent runs a command from chat, the working directory is still:

C:\

For example, Get-Location from the agent returns C:\.

I also tried changing my default terminal to CMD, but that didn’t change the agent-run command environment. Running cmd /c cd from the agent also returns C:\, so this doesn’t look like just a PowerShell-vs-CMD thing.

One extra detail: in my case, under the default sandbox/permissions, even explicitly running:

Set-Location -LiteralPath "D:\47065\Documents\wasm-optimization"; Get-Location

can hit Access is denied. But if I approve/run the same check with elevated access, it can enter the project directory correctly.

So this seems very close to what’s described here: the project/thread is tied to the right folder, but the agent command runner starts from C:\ instead of the project cwd. Also, each agent command seems to start fresh, so changing directory in one command doesn’t carry over to the next one.

I am seeing what appears to be the same issue in a newer Codex Desktop build. I was able to narrow it down further: the agent command runner's process working directory is correct, but sandboxed Windows PowerShell's own provider location is incorrectly initialized to C:\.

Environment

• Codex Desktop: 26.721.4979.0
• Bundled Codex CLI: 0.146.0-alpha.3.1
• Windows: Microsoft Windows NT 10.0.26200.0, x64
• Windows PowerShell: 5.1.26100.8875
• Workspace and repository are on C:
• The repository is configured as trusted.
• Windows sandbox configuration:

``toml
[windows]
sandbox = "elevated"
``

Provider location and process CWD disagree

The agent ran this with the repository explicitly supplied as the command workdir:

Write-Output ('PowerShell location: ' + (Get-Location).Path)
Write-Output ('Process directory: ' + [Environment]::CurrentDirectory)

The result was:

PowerShell location: C:\
Process directory: C:\path\to\repo

Test cases

I compared several execution paths using the same requested workdir:

| Execution path | Reported location |
|---|---|
| Sandboxed PowerShell: (Get-Location).Path | C:\ |
| Sandboxed PowerShell: [Environment]::CurrentDirectory | Correct repository |
| Sandboxed PowerShell with login-shell behavior disabled | Same mismatch |
| Sandboxed cmd.exe: cd | Correct repository |
| PowerShell outside the sandbox | Both values are the correct repository |

However, I have only noticed the issue intermittently during normal Codex use. I have not been routinely inspecting the agent's command traces, so I cannot yet say whether the trigger is nondeterministic or whether some earlier event puts a thread or sandbox session into this state. Once triggered here, it was stable across the repeated calls.

Workaround attempts

In this occurrence, explicitly changing location did not provide the workaround described in the issue:

Set-Location -LiteralPath 'C:\path\to\repo'

PowerShell returned:

Set-Location : Access is denied
CategoryInfo : NotSpecified
FullyQualifiedErrorId : UnauthorizedAccessException,Microsoft.PowerShell.Commands.SetLocationCommand

At the same time, commands using absolute paths could read files in the repository, and Codex could edit files there.

Disabling login-shell behavior did not change the result, which makes a PowerShell profile script less likely to be the cause. Bypassing the sandbox did correct it, but that is not an appropriate routine workaround.

This also appears to be the same underlying problem reported later in #21606.

Trace and suggested fix

See: https://github.com/openai/codex/issues/21606#issuecomment-5089399505