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

Activity

1. cyruan815

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on May 3, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   tool-callsIssues related to tool callingIssues related to tool calling

   on May 3, 2026
3. github-actions commented on May 3, 2026

   

   github-actionsBot

   on May 3, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Agent runtime CWD/worktree is not rebound when navigating between project chats #20725

   Powered by Codex Action
4. hiyocop commented on May 24, 2026

   

   hiyocop

   on May 24, 2026

   More actions

   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.
5. alamia-lab commented on Jun 10, 2026

   

   alamia-lab

   on Jun 10, 2026

   More actions

   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.
6. h3har commented on Jul 27, 2026

   

   h3har

   on Jul 27, 2026

   Last edited by h3har

   More actions

   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:

     [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: #21606 (comment)