Codex Desktop Windows PowerShell cwd / PSDrive Initialization Bug

What version of the Codex App are you using (From “About Codex” dialog)?

26.616.71553

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex Desktop on Windows appears to initialize the PowerShell shell tool with split and inconsistent filesystem state. The managed/.NET current directory is set to the requested workspace, but PowerShell's provider/session state and native child-process cwd are not. This causes commands to run from an unrelated drive (F:/, in my case) or temp directory, prevents normal PowerShell cmdlets from resolving, and prevents native tools like git from seeing the workspace. Additionally, the PowerShell FileSystem provider lacks the C: drive entirely, even though .NET APIs can access C:\... paths.

Initial Symptoms With F: Mounted

The shell tool was invoked with:

workdir = C:\Users\user.name\Documents\Codex\2026-06-23\i

Observed:

[System.IO.Directory]::GetCurrentDirectory()
# C:\Users\user.name\Documents\Codex\2026-06-23\i

$ExecutionContext.SessionState.Path.CurrentFileSystemLocation
# F:\

cmd.exe /c cd
# F:\

PowerShell filesystem drives were:

Temp | FileSystem | C:\Users\U9974~1.NAM\AppData\Local\Temp\
F    | FileSystem | F:\

Missing expected drives:

C:
I:

Core PowerShell management cmdlets were unavailable:

Get-Location
# The term 'Get-Location' is not recognized...

Get-PSDrive
# The term 'Get-PSDrive' is not recognized...

PSModulePath included the expected PowerShell 7 module directory:

C:\Program Files\PowerShell\7\Modules

The module file existed according to .NET APIs:

[System.IO.Directory]::Exists('C:\Program Files\PowerShell\7\Modules\Microsoft.PowerShell.Management')
# True

[System.IO.Directory]::GetFiles('C:\Program Files\PowerShell\7\Modules\Microsoft.PowerShell.Management')
# C:\Program Files\PowerShell\7\Modules\Microsoft.PowerShell.Management\Microsoft.PowerShell.Management.psd1

But importing failed:

Import-Module Microsoft.PowerShell.Management
# The specified module 'Microsoft.PowerShell.Management' was not loaded because no valid module file was found in any module directory.

PowerShell provider path resolution failed for absolute C:\... paths:

$ExecutionContext.SessionState.Path.GetUnresolvedProviderPathFromPSPath('C:\Users\user.name\Documents\Codex\2026-06-23\i')
# Cannot find drive. A drive with the name 'C' does not exist.

After Relaunching Codex And Ejecting F:

I fully relaunched Codex and ejected the removable F:\ drive.

Observed:

[System.IO.Directory]::GetCurrentDirectory()
# C:\Users\user.name\Documents\Codex\2026-06-23\i

$ExecutionContext.SessionState.Path.CurrentFileSystemLocation
# Temp:\

$ExecutionContext.SessionState.Path.GetUnresolvedProviderPathFromPSPath('.')
# C:\Users\U9974~1.NAM\AppData\Local\Temp\

cmd.exe /c cd
# C:\Users\U9974~1.NAM\AppData\Local\Temp\

PowerShell filesystem drives then included only:

Temp | FileSystem | C:\Users\U9974~1.NAM\AppData\Local\Temp\

Still missing:

C:
I:

Core management cmdlets were still unavailable:

Get-Location
# The term 'Get-Location' is not recognized...

Get-PSDrive
# The term 'Get-PSDrive' is not recognized...

Native commands could not access the workspace:

cmd.exe /c "dir C:\Users\user.name\Documents\Codex\2026-06-23\i"
# Access is denied.

git -C C:\Users\user.name\Documents\Codex\2026-06-23\i status --short
# fatal: not a git repository (or any of the parent directories): .git

But .NET APIs inside the shell could still see the workspace:

[System.IO.Directory]::Exists('C:\Users\user.name\Documents\Codex\2026-06-23\i')
# True

[System.IO.Directory]::GetFileSystemEntries('C:\Users\user.name\Documents\Codex\2026-06-23\i')
# C:\Users\user.name\Documents\Codex\2026-06-23\i\outputs
# C:\Users\user.name\Documents\Codex\2026-06-23\i\work

What steps can reproduce the bug?

Reproducibility

These commands will reproduce the important state:

$ExecutionContext.SessionState.Drive.GetAll() | ForEach-Object { "$($_.Name)|$($_.Provider.Name)|$($_.Root)|$($_.CurrentLocation)" }
[System.IO.Directory]::GetCurrentDirectory()
$ExecutionContext.SessionState.Path.CurrentFileSystemLocation
$ExecutionContext.SessionState.Path.GetUnresolvedProviderPathFromPSPath('.')
cmd.exe /c cd
Get-Location
Get-PSDrive -PSProvider FileSystem
git status --short

What is the expected behavior?

When the shell tool is invoked with workdir = C:\Users\user.name\Documents\Codex\2026-06-23\i:

• PowerShell provider cwd should be the workspace, not F:\ or Temp:\
• Native child processes should inherit the workspace cwd
• The FileSystem provider should expose at least the workspace drive, C:
• Built-in cmdlets from Microsoft.PowerShell.Management, such as Get-Location, Get-ChildItem, and Get-PSDrive, should be available or importable
• Native commands such as git status should execute in the workspace

Additional information

Why Care?

This breaks normal Codex repository workflows on Windows:

• git, cmd, and other native tools run from the wrong directory
• Relative paths resolve to the wrong location
• Absolute workspace paths may fail through PowerShell provider/native tooling
• Common PowerShell commands fail because core modules/cmdlets are unavailable
• The assistant may misdiagnose cwd/env-var issues as repo problems

Potential Culprit(s)

This looks like a Codex Windows shell-host or sandbox initialization issue. The host seems to patch the managed/.NET current directory to the requested workspace but does not initialize PowerShell's FileSystem provider drives, provider cwd, or native subprocess cwd consistently.

The presence of a removable F:\ drive influenced the wrong cwd, but after ejecting it the issue persisted with Temp:\, which suggests F:\ was a symptom or selected fallback rather than the root cause.

My workstation does have a dual PowerShell/PwSh installation (5.1.26100.8655 and 7.5.5), which may be a contributing environment detail, but even that should not normally cause a PowerShell 7 runspace to omit C: from FileSystem PSDrives while .NET can access C:\.

Suggested Areas of Concern

• How Codex Desktop creates Windows PowerShell runspaces for the shell tool
• Whether sandboxing/brokering strips or fails to add the workspace drive as a FileSystem PSDrive
• Whether the host sets only [System.IO.Directory]::CurrentDirectory but not PowerShell provider location
• Whether native child process cwd is initialized from a stale parent cwd rather than the requested workdir
• Whether removable or mapped drives affect initial drive selection/fallback