Windows Codex sandbox dotnet solution build fails unless NUGET_PACKAGES is overridden and -m:1 is used

What version of Codex CLI is running?

codex-cli 0.106.0

What subscription do you have?

Chatgpt plus

Which model were you using?

gpt-5.3-codex

What platform is your computer?

Microsoft Windows NT 10.0.22631.0 x64

What terminal emulator and version are you using (if applicable)?

Windows Terminal (PowerShell)

What issue are you seeing?

In the Windows Codex sandbox, solution-level dotnet restore / dotnet build for a .NET MAUI solution fails by default in a misleading way.

Environment:

• component: Codex CLI
• Codex version: codex-cli 0.106.0
• terminal: Windows Terminal / PowerShell 7.5.4
• Windows Codex sandbox
• dotnet SDK 9.0.311
• solution: project.sln
• target frameworks: net8.0-windows10.0.19041.0, net8.0-android
• Microsoft.Maui.Controls package: 8.0.100
• CommunityToolkit.Maui package: 8.0.1
• sandbox identity from whoami: hexen-beast\codexsandboxoffline

Default commands:

dotnet restore .\project.sln
dotnet build .\project.sln

Observed output:

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

The sandbox-resolved NuGet global-packages path is:

dotnet nuget locals global-packages --list

Output:

global-packages: C:\Users\CodexSandboxOffline\.nuget\packages\

If I force single-node execution, the real error becomes visible:

dotnet restore .\project.sln -m:1

Output:

error : Access to the path 'C:\Users\CodexSandboxOffline\.nuget\packages\sixlabors.imagesharp\3.1.12' is denied.

What steps can reproduce the bug?

Repro steps:

1. Start a Windows Codex CLI sandbox session.
2. In a .NET MAUI solution, run:

dotnet nuget locals global-packages --list
dotnet restore .\project.sln
dotnet build .\project.sln

1. Observe that restore/build fails with:

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

1. Run:

dotnet restore .\project.sln -m:1

1. Observe that the real failure is:

error : Access to the path 'C:\Users\CodexSandboxOffline\.nuget\packages\sixlabors.imagesharp\3.1.12' is denied.

1. Then run the workaround:

$env:NUGET_PACKAGES = Join-Path $env:USERPROFILE '.nuget\packages'
dotnet restore .\project.sln -m:1
dotnet build .\project.sln -m:1 --no-restore

1. Observe that restore/build succeeds in the sandbox.

Thread id:

• not available

What is the expected behavior?

• The default sandboxed solution-level dotnet restore / dotnet build should succeed if the repo is otherwise healthy.
• If dotnet resolves a sandbox-user NuGet cache path, that path should be usable.
• If it is not usable, the real access-denied error should be surfaced directly instead of only:

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

• The build should not require both:
• overriding NUGET_PACKAGES
• forcing single-node mode with -m:1

Additional information

• Initially presents to the end user as a failure of NuGet to reach the internet, a sandbox issue.
• Outside the sandbox, the same repo restores/builds successfully.
• Overriding NUGET_PACKAGES alone is not enough in this sandbox; -m:1 is also required.
• The workaround that succeeds is:

$env:NUGET_PACKAGES = Join-Path $env:USERPROFILE '.nuget\packages'
dotnet restore .\project.sln -m:1
dotnet build .\project.sln -m:1 --no-restore

• This suggests two related Windows sandbox issues:
• the default NuGet global-packages path resolves to C:\Users\CodexSandboxOffline\.nuget\packages, which is not reliably usable
• default multi-proc solution-level restore/build fails opaquely, while -m:1 exposes or avoids the real problem
• Possible fixes:
• preconfigure a writable NUGET_PACKAGES path in Windows Codex sandboxes
• or ensure C:\Users\CodexSandboxOffline\.nuget\packages is writable
• investigate why default multi-proc solution builds fail opaquely while -m:1 succeeds
• Possibly related (generated by codex, unverified):
• #3269 dotnet command hangs until timeout, with high cpu
• #5946 Dotnet build execution takes indefinite amount of time without success
• #6090 Windows command execution / sandbox behavior issue
• #7298 Windows shell-selection bug