dotnet build Access is Denied
What version of Codex is running?
codex-cli 0.61.0
What subscription do you have?
Chatgpt Plus
Which model were you using?
gpt-5.1-codex-max
What platform is your computer?
Microsoft Windows NT 10.0.26100.0 x64 (Windows 11 Pro)
What issue are you seeing?
When using codex in sandbox mode; workspace_write on our dotnet project it can make changes and do basic tasks just fine. An important part of the workflow we have with codex is based on it being able to verify if its changes are at least somewhat correct. (Build ok, tests ok).
After running into this failure I used codex to try and diagnose the issue but sadly never found a full solution. You can see this in the log I uploaded using the /feedback command; 019aa6b3-bf29-7520-8707-cfa34f9ea6c4
We tried using some writable roots as well as a bunch of different build flags to try and turn off as much of the caching, reuse and shared build servers as possible. After some debugging the signs we get in the logging seem to point the use of a shared pipe which codex claimed is not allowed based on analysis of the codex source code. I'm not that familiar with the dotnet compiler platform however so take my comment with a grain of salt.
What steps can reproduce the bug?
- dotnet new console
- dotnet build (also tried /m:1 /nr:false /p:UseSharedCompilation=false MSBUILDDISABLENODEREUSE=1)
- Clean build fails with the error:
C:\Program Files\dotnet\sdk\10.0.100\Roslyn\Microsoft.CSharp.Core.targets(84,5): error MSB3883: Unexpected exception
C:\Program Files\dotnet\sdk\10.0.100\Roslyn\Microsoft.CSharp.Core.targets(84,5): error: Access is denied.
What is the expected behavior?
All dotnet cli commands run properly inside of the codex sandbox in workspace_writable mode and network enabled.
Additional information
_No response_
7 Comments
having the same problem, a fix or workaround is appreciated
UPDATE: work around is to run codex like with
codex --dangerously-bypass-approvals-and-sandboxnot sure about the downside, but works.
Just add to your AGENTS.md:
... this way it will ask you and then it works fine.
We actually use the following mcp server as a stop gap solution. https://github.com/AdamTovatt/dotnet-tools-mcp-server Our AGENTS.md redirects to the mcp server. We also created a small shim that we load into the PATH for codex as if it was dotnet and it will print only the correct mcp command with instructions instead of actually invoking dotnet. This works reliably for us.
That being said if adding "Always run dotnet builds with elevated sandbox permissions" to your AGENTS.md is enough its definitely simpler.
Regarding
codex --dangerously-bypass-approvals-and-sandboxdoesn't that give codex full access to the entire system?AGENTS.md didn't work for us. The model still can't run
dotnet buildordotnet test. It asks, but is still not able to run the commands. Only if we give it full access to our system, it can run the commands.As a quick update while I don't know why, how or since when but this does seem to work again in v0.92.0. Most likely this was already fixed in an earlier version but I didn't pick up on it due to the workarounds we implemented. If there is any testing or validation needed let me know otherwise I think this issue can be closed?
Hey @Nouwan! I was looking into this 'Access Denied' issue with
dotnet buildinside the sandbox.It turns out the Windows sandbox token was missing some well-known SIDs like
EveryoneandAuthenticated Users, which the Dotnet toolchain (specifically MSBuild/Roslyn) often relies on for IPC and temporary file access.I've submitted a fix in #10648 that includes these SIDs in the restricted token and grants them default DACL access. This should let the compiler operate correctly within the restricted environment. If you're building from source, I'd love to know if this resolves the issue for your project!
Closing as resolved in current releases. Thanks for confirming.