›_ Codex Issues
Codex Issues / #18248

Windows app and CLI child processes start with missing core env vars, breaking dotnet/NuGet and git networking

Resolved 💬 5 comments Opened Apr 17, 2026 by albertc71 Closed Apr 29, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

On Windows x64, both Codex App and Codex CLI appear to launch child processes with an incomplete/broken environment block.

This breaks common tools in ways that do not reproduce in a normal Windows terminal on the same machine.

The clearest symptoms I reproduced were:

  • dotnet build / restore failing inside NuGet with Value cannot be null. (Parameter 'path1')
  • git fetch failing with getaddrinfo() thread failed to start
  • dotnet --info / dotnet nuget locals all -l behaving incorrectly until core Windows env vars are manually restored

I can reproduce the same issue in both the Codex App and Codex CLI.

See the follow-up comment(s) on this issue for sanitized failing and succeeding command logs that may be useful for debugging.

Versions / Environment

  • Codex App: 26.409.61251
  • Codex CLI: 0.121.0 (codex -V -> codex-cli 0.121.0)
  • Subscription: Pro x5
  • Platform: Windows x64
  • CLI config file: %USERPROFILE%\.codex\config.toml

Relevant Codex config

This reproduces even with a non-restrictive config.

Sanitized relevant settings from %USERPROFILE%\.codex\config.toml:

model = "gpt-5.4"
model_reasoning_effort = "xhigh"
sandbox_mode = "danger-full-access"
approval_policy = "never"

[shell_environment_policy]
inherit = "core"

[sandbox_workspace_write]
network_access = true

[windows]
sandbox = "unelevated"

This is useful context because the failure still occurs with:

  • sandbox_mode = "danger-full-access"
  • approval_policy = "never"
  • network_access = true

So the issue does not appear to require a restrictive filesystem sandbox to reproduce.

I also explicitly tried using:

[windows]
sandbox = "elevated"

Per the official Windows docs, elevated is the preferred native Windows sandbox and unelevated is the fallback. In my environment, elevated does not work correctly either, and Codex appears to fall back / fail during sandbox setup rather than resolving the underlying issue.

What appears to be wrong

Inside the Codex-launched process environment, standard Windows/user env vars are empty by default.

Observed empty vars from the Codex-run shell:

  • APPDATA=
  • LOCALAPPDATA=
  • ProgramFiles=
  • ProgramFiles(x86)=
  • SystemRoot=
  • ComSpec=
  • HOME=
  • HOMEDRIVE=
  • HOMEPATH=

This strongly suggests the issue is not just one tool failing, but that Codex is spawning subprocesses with a stripped or malformed Windows environment.

Repro 1: dotnet / NuGet restore failure

Run inside Codex:

dotnet build path\to\SearchService.sln

Observed failure:

C:\Program Files\dotnet\sdk\9.0.311\NuGet.targets(789,5): error : Value cannot be null. (Parameter 'path1')

This failed across many projects during restore.

Additional evidence:

  • dotnet --info was also broken in the Codex environment until missing env vars were restored.
  • dotnet nuget locals all -l initially failed with the same null-path style issue.

After manually setting missing Windows env vars in-process, dotnet --info and dotnet nuget locals all -l started working normally.

Then after:

  1. restoring the missing env vars in the current process
  2. running dotnet build-server shutdown
  3. rerunning dotnet restore / dotnet build with --disable-build-servers

…the same solution built successfully.

That suggests:

  • the primary bug is the broken env seen by Codex child processes
  • a secondary issue is that long-lived MSBuild/NuGet server processes can inherit that poisoned env and keep failing until restarted

Repro 2: git networking failure

Run inside Codex:

git fetch <remote> <branch>

Observed failure:

fatal: unable to access '<git-remote-url>': getaddrinfo() thread failed to start

After restoring the missing Windows env vars in-process, the same fetch succeeded.

CLI sandbox/setup evidence

I also found this file:

  • %USERPROFILE%\.codex\.sandbox\setup_error.json

Contents:

{
  "code": "helper_firewall_rule_create_or_add_failed",
  "message": "SetRemotePorts failed: Error { code: HRESULT(0x80070057), message: \"The parameter is incorrect.\" }"
}

Related log lines:

[2026-04-16T23:27:00.176161+00:00] ensuring sandbox users offline=CodexSandboxOffline online=CodexSandboxOnline
[2026-04-16T23:27:00.912931700+00:00] firewall rule configured name=codex_sandbox_offline_block_loopback_udp protocol=17 RemoteAddresses=127.0.0.0/8,::/127 RemotePorts=* LocalUserAuthorizedList=O:LSD:(A;;CC;;;S-1-5-21-3710022093-1345025342-3600534460-1008)
[2026-04-16T23:27:01.377786800+00:00] firewall rule configured name=codex_sandbox_offline_block_loopback_tcp protocol=6 RemoteAddresses=127.0.0.0/8,::/127 RemotePorts=* LocalUserAuthorizedList=O:LSD:(A;;CC;;;S-1-5-21-3710022093-1345025342-3600534460-1008)
[2026-04-16T23:27:01.866423200+00:00] firewall rule configured name=codex_sandbox_offline_block_loopback_tcp protocol=6 RemoteAddresses=127.0.0.0/8,::/127 RemotePorts=1-65535 LocalUserAuthorizedList=O:LSD:(A;;CC;;;S-1-5-21-3710022093-1345025342-3600534460-1008)
[2026-04-16T23:27:01.895732600+00:00] setup error: helper_firewall_rule_create_or_add_failed: SetRemotePorts failed: Error { code: HRESULT(0x80070057), message: "The parameter is incorrect." }
[2026-04-17 00:27:01.895 codex-windows-sandbox-setup.exe] setup error: helper_firewall_rule_create_or_add_failed: SetRemotePorts failed: Error { code: HRESULT(0x80070057), message: "The parameter is incorrect." }

I do not know whether this firewall/sandbox setup failure is the root cause or a separate Windows bug, but I am including it because the overall behavior looks like a Codex Windows process-launch/sandbox/environment problem rather than a repo-specific tool problem.

Additional observed command log excerpts

[2026-04-17 02:19:48.849 codex.exe] START: C:\Program Files\PowerShell\7\pwsh.exe -Command [Console]::OutputEncoding=[System.Text.Encoding]::UTF8;
dotnet build path\to\SearchService.sln
[2026-04-17 02:36:22.069 codex.exe] FAILURE: C:\Program Files\PowerShell\7\pwsh.exe -Command [Console]::OutputEncoding=[System.Text.Encoding]::UTF8;
dotnet build path\to\SearchService.sln (exit code 1)

Expected behavior

Child processes launched by Codex App and Codex CLI on Windows should inherit a valid Windows user/system environment comparable to a normal terminal session, unless intentionally overridden.

At minimum, core vars such as these should not be empty:

  • APPDATA
  • LOCALAPPDATA
  • ProgramFiles
  • ProgramFiles(x86)
  • SystemRoot
  • ComSpec
  • HOME
  • HOMEDRIVE
  • HOMEPATH

Actual behavior

Codex-launched processes appear to start with missing core Windows env vars, leading to downstream failures in:

  • .NET / NuGet path resolution
  • git/curl networking
  • possibly sandbox/firewall setup or related Windows helper behavior

Workaround

In my case, manually setting the missing Windows env vars in-process allowed the tools to start behaving normally.

For .NET specifically, I also had to run:

dotnet build-server shutdown

and then rerun restore/build with build servers disabled so stale processes would not keep the broken environment.

Why I think this is not repo-specific

  • It reproduces in both Codex App and Codex CLI
  • The same machine works in a normal terminal
  • Multiple unrelated tools break in different ways until the env is repaired
  • The failures line up with missing Windows/user env vars, not project configuration

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 4 months ago

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

  • #18110
  • #17020
  • #17686
  • #17458

Powered by Codex Action

albertc71 · 4 months ago

Sanitized follow-up logs showing the failure first, then the successful workaround after manually restoring the missing Windows env vars and forcing fresh .NET build servers.

I redacted product/repo-specific identifiers, branch, commit, and user-specific paths.

1. Failing build in the default Codex-launched environment

Sanitized command:

dotnet build "path\\to\\<redacted-search-service>.sln"

Sanitized observed output:

  Determining projects to restore...
C:\Program Files\dotnet\sdk\9.0.311\NuGet.targets(789,5): error : Value cannot be null. (Parameter 'path1') [C:\repos\<workspace>\core\api\<redacted-search-service>\<redacted-search-tests>\<redacted-search-tests>.csproj]
C:\Program Files\dotnet\sdk\9.0.311\NuGet.targets(789,5): error : Value cannot be null. (Parameter 'path1') [C:\repos\<workspace>\core\api\<redacted-search-service>\<redacted-search-service-interface>\<redacted-search-service-interface>.csproj]
C:\Program Files\dotnet\sdk\9.0.311\NuGet.targets(789,5): error : Value cannot be null. (Parameter 'path1') [C:\repos\<workspace>\core\framework\<redacted-elasticsearch-framework>\<redacted-elasticsearch-framework>\<redacted-elasticsearch-framework>.csproj]
C:\Program Files\dotnet\sdk\9.0.311\NuGet.targets(789,5): error : Value cannot be null. (Parameter 'path1') [C:\repos\<workspace>\core\framework\<redacted-servicestack-framework>\<redacted-servicestack-framework>\<redacted-servicestack-framework>.csproj]
C:\Program Files\dotnet\sdk\9.0.311\NuGet.targets(789,5): error : Value cannot be null. (Parameter 'path1') [C:\repos\<workspace>\core\framework\<redacted-application-framework>\<redacted-application-framework>\<redacted-application-framework>.csproj]
C:\Program Files\dotnet\sdk\9.0.311\NuGet.targets(789,5): error : Value cannot be null. (Parameter 'path1') [C:\repos\<workspace>\core\framework\<redacted-servicestack-servicemodel>\<redacted-servicestack-servicemodel>.csproj]
C:\Program Files\dotnet\sdk\9.0.311\NuGet.targets(789,5): error : Value cannot be null. (Parameter 'path1') [C:\repos\<workspace>\core\framework\<redacted-security-framework>\<redacted-security-framework>\<redacted-security-framework>.csproj]
C:\Program Files\dotnet\sdk\9.0.311\NuGet.targets(789,5): error : Value cannot be null. (Parameter 'path1') [C:\repos\<workspace>\core\framework\<redacted-resiliency-framework>\<redacted-resiliency-framework>\<redacted-resiliency-framework>.csproj]
C:\Program Files\dotnet\sdk\9.0.311\NuGet.targets(789,5): error : Value cannot be null. (Parameter 'path1') [C:\repos\<workspace>\core\framework\<redacted-backgroundtasks-framework>\<redacted-backgroundtasks-framework>\<redacted-backgroundtasks-framework>.csproj]
C:\Program Files\dotnet\sdk\9.0.311\NuGet.targets(789,5): error : Value cannot be null. (Parameter 'path1') [C:\repos\<workspace>\core\framework\<redacted-logging-web-framework>\<redacted-logging-web-framework>\<redacted-logging-web-framework>.csproj]
C:\Program Files\dotnet\sdk\9.0.311\NuGet.targets(789,5): error : Value cannot be null. (Parameter 'path1') [C:\repos\<workspace>\core\framework\<redacted-logging-framework>\<redacted-logging-framework>\<redacted-logging-framework>.csproj]
C:\Program Files\dotnet\sdk\9.0.311\NuGet.targets(789,5): error : Value cannot be null. (Parameter 'path1') [C:\repos\<workspace>\core\api\<redacted-search-service>\<redacted-search-service>\<redacted-search-service>.csproj]
C:\Program Files\dotnet\sdk\9.0.311\NuGet.targets(789,5): error : Value cannot be null. (Parameter 'path1') [C:\repos\<workspace>\core\framework\<redacted-aws-framework>\<redacted-aws-framework>\<redacted-aws-framework>.csproj]
C:\Program Files\dotnet\sdk\9.0.311\NuGet.targets(789,5): error : Value cannot be null. (Parameter 'path1') [C:\repos\<workspace>\core\framework\<redacted-application-interfaces-framework>\<redacted-application-interfaces-framework>.csproj]
C:\Program Files\dotnet\sdk\9.0.311\NuGet.targets(789,5): error : Value cannot be null. (Parameter 'path1') [C:\repos\<workspace>\core\lib\<redacted-caching-lib>\<redacted-caching-lib>\<redacted-caching-lib>.csproj]
C:\Program Files\dotnet\sdk\9.0.311\NuGet.targets(789,5): error : Value cannot be null. (Parameter 'path1') [C:\repos\<workspace>\core\api\<redacted-enums-api>\<redacted-enums-api>.csproj]
C:\Program Files\dotnet\sdk\9.0.311\NuGet.targets(789,5): error : Value cannot be null. (Parameter 'path1') [C:\repos\<workspace>\core\api\<redacted-search-service>\<redacted-search-logic>\<redacted-search-logic>.csproj]
C:\Program Files\dotnet\sdk\9.0.311\NuGet.targets(789,5): error : Value cannot be null. (Parameter 'path1') [C:\repos\<workspace>\core\api\<redacted-search-service>\<redacted-search-service-model>\<redacted-search-service-model>.csproj]
C:\Program Files\dotnet\sdk\9.0.311\NuGet.targets(789,5): error : Value cannot be null. (Parameter 'path1') [C:\repos\<workspace>\core\api\<redacted-api-framework-servicemodel>\<redacted-api-framework-servicemodel>.csproj]

Build FAILED.

2. Same build succeeds after restoring missing env vars and resetting build servers

Sanitized command:

$env:APPDATA='%USERPROFILE%\\AppData\\Roaming'
$env:LOCALAPPDATA='%USERPROFILE%\\AppData\\Local'
$env:ProgramFiles='C:\\Program Files'
${env:ProgramFiles(x86)}='C:\\Program Files (x86)'
$env:SystemRoot='C:\\Windows'
$env:ComSpec='C:\\Windows\\System32\\cmd.exe'
$env:HOMEDRIVE='C:'
$env:HOMEPATH='\\Users\\<redacted-user>'

dotnet build-server shutdown
dotnet build "path\\to\\<redacted-search-service>.sln" --disable-build-servers

Sanitized observed output:

Shutting down MSBuild server...
Shutting down VB/C# compiler server...
VB/C# compiler server shut down successfully.
MSBuild server shut down successfully.
  Determining projects to restore...
  All projects are up-to-date for restore.
  <redacted-framework-project-1> -> C:\repos\<workspace>\...\bin\Debug\net8.0\<redacted-framework-project-1>.dll
  <redacted-framework-project-2> -> C:\repos\<workspace>\...\bin\Debug\net8.0\<redacted-framework-project-2>.dll
  <redacted-search-service-model> -> C:\repos\<workspace>\...\bin\Debug\netstandard2.0\<redacted-search-service-model>.dll
  <redacted-search-service-model> -> C:\repos\<workspace>\...\bin\Debug\net48\<redacted-search-service-model>.dll
  <redacted-caching-lib> -> C:\repos\<workspace>\...\bin\Debug\netstandard2.0\<redacted-caching-lib>.dll
  ...
  No commit ID provided, determining current commit ID from Git...
  Current commit ID from Git: <redacted-commit>
  No Git branch provided, determining current branch from Git...
  Current Git branch from Git: <redacted-branch>
  Processing file: C:\repos\<workspace>\core\api\<redacted-search-service>\<redacted-search-service>\environment\platform.env
  Adding Deployment Monitoring header section
  Adding new CURRENT_COMMIT_ID to C:\repos\<workspace>\core\api\<redacted-search-service>\<redacted-search-service>\environment\platform.env
  Adding new GIT_BRANCH to C:\repos\<workspace>\core\api\<redacted-search-service>\<redacted-search-service>\environment\platform.env
  Adding new BUILD_NUMBER to C:\repos\<workspace>\core\api\<redacted-search-service>\<redacted-search-service>\environment\platform.env
  Adding new BUILD_LABEL to C:\repos\<workspace>\core\api\<redacted-search-service>\<redacted-search-service>\environment\platform.env
  Successfully updated C:\repos\<workspace>\core\api\<redacted-search-service>\<redacted-search-service>\environment\platform.env with build and Git information
  Completed processing 1 file(s)
  <redacted-search-service-interface> -> C:\repos\<workspace>\...\bin\Debug\net8.0\<redacted-search-service-interface>.dll
  <redacted-search-tests> -> C:\repos\<workspace>\...\bin\Debug\net8.0\<redacted-search-tests>.dll
  <redacted-search-service> -> C:\repos\<workspace>\...\bin\Debug\net8.0\<redacted-search-service>.dll
    <redacted-search-service> -> C:\repos\<workspace>\...\publish\

Build succeeded.
    0 Warning(s)
    0 Error(s)

This seems like a strong signal that the failing state is not the project itself, but the process environment Codex starts with plus any long-lived helper/build-server processes that inherit that bad environment.

PIGzyj233 · 4 months ago

I hit what looks like the same root cause today on Windows, but with a more direct confirmation path.

My local Codex config had:

network_access = "enabled"
sandbox_mode = "workspace-write"

[shell_environment_policy]
inherit = "core"

[sandbox_workspace_write]
network_access = true

[windows]
sandbox = "elevated"

Inside the Codex-run shell, these vars were unset by default:

  • SystemRoot
  • WINDIR
  • ComSpec
  • APPDATA
  • LOCALAPPDATA
  • ProgramData

Symptoms in the Codex-run process:

  • mb auth status succeeded (local auth state only)
  • mb db list failed with Error: fetch failed
  • curl.exe -I https://metabase.vrviu.com/api/session failed with curl: (6) getaddrinfo() thread failed to start
  • Invoke-WebRequest failed with a Windows service-provider initialization error
  • [System.Net.Dns]::GetHostAddresses(...) threw a SocketException

The key confirmation was this: after I restored those missing Windows vars in the same process, DNS and networking immediately started working again.

For example, after setting:

  • SystemRoot=C:\Windows
  • WINDIR=C:\Windows
  • ComSpec=C:\Windows\System32\cmd.exe
  • APPDATA=C:\Users\<user>\AppData\Roaming
  • LOCALAPPDATA=C:\Users\<user>\AppData\Local
  • ProgramData=C:\ProgramData

all of these started working right away from the Codex-run shell:

  • [System.Net.Dns]::GetHostAddresses('metabase.vrviu.com')
  • curl.exe -I https://metabase.vrviu.com/api/session
  • mb db list

So at least in my case, this was not just a generic sandbox/network failure. It was specifically caused by Windows child processes being launched with an incomplete environment when shell_environment_policy.inherit = "core" is used.

A likely fix is to expand the Windows allowlist for core inheritance so it includes at minimum:

  • APPDATA
  • LOCALAPPDATA
  • PROGRAMDATA
  • COMSPEC
  • SYSTEMROOT
  • WINDIR
  • USERPROFILE
  • HOMEDRIVE
  • HOMEPATH
  • SYSTEMDRIVE

I verified locally that restoring the first six above was enough to make DNS + curl + mb db list recover immediately.

albertc71 · 4 months ago

I found a workaround that may help narrow this down.

I had the following settings in my config:

sandbox_mode = "danger-full-access"
approval_policy = "never"

[shell_environment_policy]
inherit = "core"

[sandbox_workspace_write]
network_access = true

[windows]
sandbox = "elevated"

After removing them and restarting Codex, the app prompted me to set up the sandbox again.

Once that setup completed, behavior returned to normal:

  • In Default permissions, Codex now asks for approval when it tries to run a command that the sandbox rejects, and the command runs successfully after approval.
  • In Full access, the same commands run successfully without prompting.

I tested this with git fetch origin <branch> and dotnet build.

So this may be related to those config overrides or to how Codex handles sandbox state after they are changed.

iceweasel-oai contributor · 4 months ago

https://github.com/openai/codex/pull/20089 should address the problem where inherit = "core" doesn't work on Windows.