You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Dotnet build execution takes indefinite amount of time without success #5946
Asked the agent to run dotnet build and fix errors from the output (it made some while implementing changes in previous session). The build of the solution takes around 4 seconds when ran from IDE, while in CLI it was reportedly running for a minute and didn't yield any results. The previous session i waited around 10 minutes with same conclusion
Codex version 0.55 OpenAI Codex (v0.55.0)
Model gpt-5-codex
MacBookPro - Apple M3 Max
Mac OS Sequoia Version 15.7.1 (24G231)
After no progress, I stopped codex, manually ran a restore, then instructed codex to try a build with the no-restore flag. No additional progress.
Ran dotnet build --no-restore my-solution.sln
└ (no output)
• It looks like the build is timing out after 120 seconds. I’m thinking about extending the timeout_ms to something more significant—like 600,000 milliseconds. I’ll also use --no-restore to help with this issue. Getting more time might allow the build to succeed,
so let’s fetch any errors and gather more information on this!
• Ran dotnet build --no-restore my-solution.sln
└
Build FAILED.
… +2 lines
Time Elapsed 00:05:00.86
• It seems the build output indicates a failure without any errors reported. This could be due to output truncation or not capturing earlier logs. I think I'll try to run the command with tee to save the logs and also consider using dotnet msbuild for more details.
Narrowing the build process might help isolate any hidden compile errors, especially related to the Microsoft Graph upgrade. Starting with the key project could streamline getting clarity on what's going wrong!
• Ran dotnet build --no-restore src/Project/API/GatewayService.csproj
└ (no output)
• I’m exploring ways to expedite the build process, especially since it times out at 5 minutes. I’m considering using dotnet build ... -v minimal or -maxcpucount:1 to potentially speed things up, though I know it might still take around 5 minutes. It seems like
producing an msbuild binary log could help gather error information. I also think about extending the timeout to 15 minutes, which might be necessary given the size of the solution. My main goal is to streamline things while capturing any errors efficiently.
• Running dotnet build --no-restore my-solution.sln
• Optimizing build process (21m 48s • esc to interrupt)
Just confirming that this is still an issue on 0.64.0 with following observed
dotnet restore
/opt/homebrew/Library/Homebrew/cmd/shellenv.sh: line 18: /bin/ps: Operation not permitted
• I’m looking into the restore command failing with exit code 124, which likely means a timeout rather than a permission
issue. The error mentions problems with the ps command, possibly due to sandbox or macOS restrictions. It seems the
restore might still be running quietly or stuck. I’m considering retrying with a longer timeout (like 300 seconds)
without escalation first to see if that resolves the issue. Requesting approval before escalating permissions also seems
prudent since it might not be needed. Let's try a careful, extended rerun.
Uploaded a thread jic 019ae1ec-8086-73b3-8c60-f5ddcf38d2e6
@mattxo that was always the case, or alternatively as shared here #3269 (comment) setting up custom instructions. But that's more of a "workaround" and changing approvals back and forth also isn't ideal
Today's 0.66.0 update that has the following feature #7033 makes life easier: after Codex remembers the "allow always" for dotnet commands the issues described in this ticket don't happen anymore
I'm having luck telling the agent to use -m:1 flag. After some testing, telling the agent to run dotnet build and dotnet build -m:1 I'm consistently seeing:
Dotnet build produces no output and never completes
-m:1 flag always runs and builds successfully and the agent can see its output as expected
In my case the reason was that the default sandbox mode doesn't allow network access, which dotnet build requires (for restore, I suppose). So I added the following to ~/.codex/config.toml:
Oh yes good catch, the reason is the restore. You can also tell Codex to use the --no-restore flag. For reference this is my Agents.MD file instructions which works without enabling network access in the sandbox.
## Dotnet CLI Usage
In the codex sandbox, run dotnet commands that build in single node mode and without restore.
Use `-m:1 --no-restore` for `dotnet build` and for any command that triggers a build, such as `dotnet test`.
If you do not do this, the builds may sit indefinitely and produce no output.
Activity
github-actions commentedon Oct 30, 2025
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
full-autodoesn't activateon-failureapproval policy #4847Powered by Codex Action
AndrewNikolin commentedon Oct 30, 2025
For comparison ran same prompt in copilot cli which successfully built the solution and retrieved the output of build command
fix(exec): abort PTY readers after forced termination (openai#5946)
MattCosturos commentedon Nov 21, 2025
Seeing the same thing with a dotnet project.
Codex version 0.55
OpenAI Codex (v0.55.0)Model
gpt-5-codexMacBookPro - Apple M3 Max
Mac OS Sequoia
Version 15.7.1 (24G231)After no progress, I stopped codex, manually ran a restore, then instructed codex to try a build with the no-restore flag. No additional progress.
etraut-openai commentedon Nov 21, 2025
@MattCosturos, you're running a relatively old version of the CLI. Please update to the latest (0.61.0 or newer).
coen22 commentedon Nov 24, 2025
@etraut-openai it still occurs on the latest OpenAI Codex (v0.63.0)
igbenic commentedon Nov 28, 2025
Same problem, keeps wasting tokens
AndrewNikolin commentedon Dec 3, 2025
Just confirming that this is still an issue on 0.64.0 with following observed
Uploaded a thread jic
019ae1ec-8086-73b3-8c60-f5ddcf38d2e6mattxo commentedon Dec 3, 2025
I've had success on 0.64.0, the gotcha was that it requires /approvals Agent (full access)
AndrewNikolin commentedon Dec 3, 2025
@mattxo that was always the case, or alternatively as shared here #3269 (comment) setting up custom instructions. But that's more of a "workaround" and changing approvals back and forth also isn't ideal
AndrewNikolin commentedon Dec 9, 2025
Today's 0.66.0 update that has the following feature #7033 makes life easier: after Codex remembers the "allow always" for dotnet commands the issues described in this ticket don't happen anymore
linjmeyer commentedon Mar 11, 2026
I'm having luck telling the agent to use
-m:1flag. After some testing, telling the agent to rundotnet buildanddotnet build -m:1I'm consistently seeing:-m:1flag always runs and builds successfully and the agent can see its output as expectedmatteocontrini commentedon Mar 12, 2026
In my case the reason was that the default sandbox mode doesn't allow network access, which
dotnet buildrequires (for restore, I suppose). So I added the following to~/.codex/config.toml:linjmeyer commentedon Mar 12, 2026
Oh yes good catch, the reason is the restore. You can also tell Codex to use the
--no-restoreflag. For reference this is my Agents.MD file instructions which works without enabling network access in the sandbox.