Unable to run unit tests with dotnet cli

potentially related to https://github.com/openai/codex/issues/1276

This is definitely not related to #1276 because that issue pertains to cloud environments, and you're running the CLI on a local environment.

This is likely related to either the sandbox or the shell environment. You could check on the sandbox by attempting to run it in "Full Access" (yolo) mode. If that doesn't fix it, you'll probably need to do some additional debugging and investigation on your own to figure out why it's not working.

i am running into this issue as well, seems to be connected to sandbox preventing socket access - it also breaks dotnet build which usually uses a build server. If build server is disabled via a env variable, build works ok. For test, codex had to create a c# test runner to be able to run tests. both run without issue on with Full Access on. i've experienced this both on linux and macos.

i've asked codex to explain what it found and its workarounds:

Summary

Standard .NET build and test commands are not reliably usable inside the Codex desktop sandbox because several parts of the .NET toolchain use background processes, IPC, or local sockets.

There are two separate problems:

1. dotnet build may use the MSBuild server, reusable MSBuild nodes, the shared Roslyn compiler, and .NET diagnostics IPC. These must all be explicitly disabled.
2. Even after making the build socket-free, dotnet test still fails because VSTest unconditionally attempts to bind a TCP listener for communication with its test host.

Environment

• Codex desktop app on macOS ARM64
• Sandbox mode: workspace-write
• .NET 10
• VSTest 18.0.1 ARM64
• xUnit 2.9.2
• Microsoft.NET.Test.Sdk 17.11.1

Problem 1: dotnet build

A plain command such as:

dotnet build robRezCoreTests/robRezCoreTests.csproj

is not safe/reliable in the sandbox because the .NET build toolchain may start or communicate with:

• the persistent MSBuild server;
• reusable MSBuild worker nodes;
• the shared Roslyn compiler server (VBCSCompiler);
• .NET diagnostic endpoints;
• parallel build workers.

These facilities use local IPC or sockets that can be rejected by the sandbox or cause the command to hang.

The build only worked reliably after disabling all of them:

DOTNET_CLI_USE_MSBUILD_SERVER=0 \
MSBUILDDISABLENODEREUSE=1 \
DOTNET_EnableDiagnostics=0 \
COMPlus_EnableDiagnostics=0 \
dotnet build robRezCoreTests/robRezCoreTests.csproj \
  --no-restore \
  --disable-build-servers \
  -m:1 \
  -p:UseSharedCompilation=false \
  -nr:false

Relevant settings:

• DOTNET_CLI_USE_MSBUILD_SERVER=0 disables the persistent CLI MSBuild server.
• MSBUILDDISABLENODEREUSE=1 disables reusable MSBuild nodes.
• -nr:false also disables MSBuild node reuse.
• -p:UseSharedCompilation=false disables the shared Roslyn compiler process.
• -m:1 avoids parallel MSBuild workers.
• DOTNET_EnableDiagnostics=0 and COMPlus_EnableDiagnostics=0 disable runtime diagnostic IPC.
• --disable-build-servers disables available build servers.

It would be helpful if Codex either applied these settings automatically for sandboxed .NET builds or documented a supported socket-free build command.

Problem 2: dotnet test

Applying the same restrictions allows the build phase of dotnet test to finish, but the test phase still aborts before executing any tests:

DOTNET_CLI_USE_MSBUILD_SERVER=0 \
MSBUILDDISABLENODEREUSE=1 \
DOTNET_EnableDiagnostics=0 \
COMPlus_EnableDiagnostics=0 \
dotnet test robRezCoreTests/robRezCoreTests.csproj \
  --no-restore \
  --filter "FullyQualifiedName~Edit_WhenCebelcaIsTestOnly_DoesNotCallCebelca" \
  --disable-build-servers \
  -m:1 \
  -p:UseSharedCompilation=false \
  -nr:false

The failure is:

System.Net.Sockets.SocketException (13): Permission denied
   at System.Net.Sockets.Socket.Bind(EndPoint localEP)
   at System.Net.Sockets.TcpListener.Start(Int32 backlog)
   at Microsoft.VisualStudio.TestPlatform.CommunicationUtilities.SocketServer.Start(String endPoint)
   at Microsoft.VisualStudio.TestPlatform.CommunicationUtilities.TestRequestSender.InitializeCommunication()
   at Microsoft.VisualStudio.TestPlatform.CrossPlatEngine.Client.ProxyOperationManager.SetupChannel(...)
   at Microsoft.VisualStudio.TestPlatform.CrossPlatEngine.Client.ProxyExecutionManager.InitializeTestRun(...)

Test Run Aborted.

No test is executed. The failure occurs when VSTest tries to bind its internal TCP listener.

The build-related flags do not affect this listener because it is part of VSTest’s controller/test-host communication protocol, not MSBuild or .NET diagnostics.

Expected behavior

Codex should support ordinary .NET build and test workflows without requiring project-specific workarounds.

Possible solutions include:

1. Permit sandboxed loopback-only IPC and socket communication between trusted .NET build/test processes.
2. Automatically configure socket-free MSBuild and compiler operation inside the sandbox.
3. Provide a documented VSTest transport that does not use TCP.
4. Detect dotnet build and dotnet test and apply the necessary sandbox profile automatically.

Workaround used

For builds, I disabled every known background server and IPC feature using the command shown above.

For tests, that was insufficient because VSTest still required a TCP listener. I therefore bypassed VSTest:

1. Built the test assembly using the restricted build command.
2. Created a temporary console executable.
3. Loaded the compiled test assembly through AssemblyLoadContext.
4. Located selected xUnit [Fact] methods through reflection.
5. Invoked and awaited those test methods directly.
6. Loaded managed dependencies from the test output directory.
7. Supplied the SQLite native-library directory through DYLD_LIBRARY_PATH.
8. Ran the executable directly with dotnet runner.dll.

This allowed focused tests to run without VSTest sockets.

It is not a general replacement for a test runner because it bypasses normal test discovery, theories, fixtures, parallelization, timeouts, output capture, and other VSTest/xUnit runner behavior.