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