dotnet build command immediately crashing when called by Codex CLI
Open 💬 1 comment Opened Mar 8, 2026 by nkosi23
What version of Codex CLI is running?
codex-cli 0.111.0
What subscription do you have?
Codex Plus
Which model were you using?
gpt-5.4 medium
What platform is your computer?
Linux 6.18.8-1-default x86_64 x86_64
What terminal emulator and version are you using (if applicable)?
Konsole
What issue are you seeing?
Codex is not able to run any "dotnet build" command, even though the commands it attempt to run work perfectly when i run it outside of codex.
When codex calls it, the dotnet command core dumps immediately. All dotnet build commands are impacted, independently from the parameters being used.
As a result, codex is not able to build my dotnet project, which has the major impact you can imagine. This is bearable since it writes mainly correct code, but a major inconvenience.
Here is the core dump
PID: 171664 (dotnet)
UID: 1000 ([USER])
GID: 1000 ([GROUP])
Signal: 6 (ABRT)
Timestamp: Sat 2026-03-07 20:37:12 CET
Command Line: /usr/share/dotnet/dotnet /usr/share/dotnet/sdk/9.0.200/MSBuild.dll /nologo /nodemode:1 /nodeReuse:true /low:false
Executable: /usr/share/dotnet/dotnet
Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-org.kde.konsole.scope
Unit: user@1000.service
User Unit: app-org.kde.konsole.scope
Slice: user-1000.slice
Owner UID: 1000 ([USER])
Boot ID: [REDACTED_BOOT_ID]
Machine ID: [REDACTED_MACHINE_ID]
Hostname: [REDACTED_HOSTNAME]
Storage: /var/lib/systemd/coredump/core.dotnet.1000.[REDACTED].171664.zst
Size on Disk: 5.4M
Message: Process 171664 (dotnet) of user 1000 dumped core.
Stack trace of thread 171664:
#0 0x00007fc03729dd3c __pthread_kill_implementation (libc.so.6 + 0x9dd3c)
#1 0x00007fc0372427b6 raise (libc.so.6 + 0x427b6)
#2 0x00007fc03722934b abort (libc.so.6 + 0x2934b)
#3 0x00007fc037071909 n/a (libcoreclr.so + 0x671909)
#4 0x00007fc037071829 n/a (libcoreclr.so + 0x671829)
#5 0x00007fc036dfd8f7 n/a (libcoreclr.so + 0x3fd8f7)
... [Remaining stack frames preserved for debugging] ...
#29 0x000056281e7a2bda n/a (/usr/share/dotnet/dotnet + 0x6bda)
Stack trace of thread 171784:
#0 0x00007fc0372a4812 __syscall_cancel_arch (libc.so.6 + 0xa4812)
#1 0x00007fc037298008 __internal_syscall_cancel (libc.so.6 + 0x98008)
#2 0x00007fc0372987cc __futex_abstimed_wait_common (libc.so.6 + 0x987cc)
#3 0x00007fc03729b4e5 pthread_cond_timedwait@@GLIBC_2.3.2 (libc.so.6 + 0x9b4e5)
#4 0x00007fc03706a095 n/a (libcoreclr.so + 0x66a095)
#5 0x00007fc037069cfa n/a (libcoreclr.so + 0x669cfa)
#6 0x00007fc03706e8d2 n/a (libcoreclr.so + 0x66e8d2)
#7 0x00007fc03706eaa9 n/a (libcoreclr.so + 0x66eaa9)
#8 0x00007fc036dcae7e n/a (libcoreclr.so + 0x3cae7e)
#9 0x00007fc036d3cfff n/a (libcoreclr.so + 0x33cfff)
#10 0x00007fc036d3d1ff n/a (libcoreclr.so + 0x33d1ff)
#11 0x00007fc036cceb88 n/a (libcoreclr.so + 0x2ceb88)
#12 0x00007fc036ccf08d n/a (libcoreclr.so + 0x2cf08d)
#13 0x00007fc036d3d438 n/a (libcoreclr.so + 0x33d438)
#14 0x00007fc03707592e n/a (libcoreclr.so + 0x67592e)
#15 0x00007fc03729bdf1 start_thread (libc.so.6 + 0x9bdf1)
#16 0x00007fc037320c8c __clone3 (libc.so.6 + 0x120c8c)
Stack trace of thread 172211:
#0 0x00007fc0372a4812 __syscall_cancel_arch (libc.so.6 + 0xa4812)
#1 0x00007fc037298008 __internal_syscall_cancel (libc.so.6 + 0x98008)
#2 0x00007fc037298061 __syscall_cancel (libc.so.6 + 0x98061)
#3 0x00007fc037320fa1 epoll_wait (libc.so.6 + 0x120fa1)
#4 0x00007fc0374288a2 SystemNative_WaitForSocketEvents (libSystem.Native.so + 0x128a2)
#5 0x00007fbfb9ec0453 n/a (n/a + 0x0)
#6 0x00007fbfb9ee4b71 n/a (n/a + 0x0)
#7 0x00007fc036ec2d84 n/a (libcoreclr.so + 0x4c2d84)
#8 0x00007fc036d00985 n/a (libcoreclr.so + 0x300985)
#9 0x00007fc036d16642 n/a (libcoreclr.so + 0x316642)
#10 0x00007fc036cceb88 n/a (libcoreclr.so + 0x2ceb88)
#11 0x00007fc036ccf03d n/a (libcoreclr.so + 0x2cf03d)
#12 0x00007fc036d1675c n/a (libcoreclr.so + 0x31675c)
#13 0x00007fc03707592e n/a (libcoreclr.so + 0x67592e)
#14 0x00007fc03729bdf1 start_thread (libc.so.6 + 0x9bdf1)
#15 0x00007fc037320c8c __clone3 (libc.so.6 + 0x120c8c)
Stack trace of thread 171778:
#0 0x00007fc0372a4812 __syscall_cancel_arch (libc.so.6 + 0xa4812)
#1 0x00007fc037298008 __internal_syscall_cancel (libc.so.6 + 0x98008)
#2 0x00007fc0372987cc __futex_abstimed_wait_common (libc.so.6 + 0x987cc)
#3 0x00007fc03729b308 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x9b308)
#4 0x00007fc03706a0f2 n/a (libcoreclr.so + 0x66a0f2)
#5 0x00007fc037069cfa n/a (libcoreclr.so + 0x669cfa)
#6 0x00007fc03706e8d2 n/a (libcoreclr.so + 0x66e8d2)
#7 0x00007fc03706eb83 n/a (libcoreclr.so + 0x66eb83)
#8 0x00007fc036f6c02d n/a (libcoreclr.so + 0x56c02d)
#9 0x00007fc036f6bea8 n/a (libcoreclr.so + 0x56bea8)
#10 0x00007fc036f6bba5 n/a (libcoreclr.so + 0x56bba5)
#11 0x00007fc03707592e n/a (libcoreclr.so + 0x67592e)
#12 0x00007fc03729bdf1 start_thread (libc.so.6 + 0x9bdf1)
#13 0x00007fc037320c8c __clone3 (libc.so.6 + 0x120c8c)
Stack trace of thread 172139:
#0 0x00007fc0372a4812 __syscall_cancel_arch (libc.so.6 + 0xa4812)
#1 0x00007fc037298008 __internal_syscall_cancel (libc.so.6 + 0x98008)
#2 0x00007fc037298061 __syscall_cancel (libc.so.6 + 0x98061)
#3 0x00007fc037312f7a read (libc.so.6 + 0x112f7a)
#4 0x00007fc03742a7ff n/a (libSystem.Native.so + 0x147ff)
#5 0x00007fc03729bdf1 start_thread (libc.so.6 + 0x9bdf1)
#6 0x00007fc037320c8c __clone3 (libc.so.6 + 0x120c8c)
Stack trace of thread 171764:
#0 0x00007fc0372a4812 __syscall_cancel_arch (libc.so.6 + 0xa4812)
#1 0x00007fc037298008 __internal_syscall_cancel (libc.so.6 + 0x98008)
#2 0x00007fc037298061 __syscall_cancel (libc.so.6 + 0x98061)
#3 0x00007fc0373129aa __poll (libc.so.6 + 0x1129aa)
#4 0x00007fc03706c10e n/a (libcoreclr.so + 0x66c10e)
#5 0x00007fc03707592e n/a (libcoreclr.so + 0x67592e)
#6 0x00007fc03729bdf1 start_thread (libc.so.6 + 0x9bdf1)
#7 0x00007fc037320c8c __clone3 (libc.so.6 + 0x120c8c)
Stack trace of thread 171998:
#0 0x00007fc0372a4812 __syscall_cancel_arch (libc.so.6 + 0xa4812)
#1 0x00007fc037298008 __internal_syscall_cancel (libc.so.6 + 0x98008)
#2 0x00007fc0372987cc __futex_abstimed_wait_common (libc.so.6 + 0x987cc)
#3 0x00007fc03729b4e5 pthread_cond_timedwait@@GLIBC_2.3.2 (libc.so.6 + 0x9b4e5)
#4 0x00007fc03706a095 n/a (libcoreclr.so + 0x66a095)
#5 0x00007fc037069cfa n/a (libcoreclr.so + 0x669cfa)
#6 0x00007fc03706f009 n/a (libcoreclr.so + 0x66f009)
#7 0x00007fc036cd242a n/a (libcoreclr.so + 0x2d242a)
#8 0x00007fc036cd22e8 n/a (libcoreclr.so + 0x2d22e8)
#9 0x00007fc036cceb88 n/a (libcoreclr.so + 0x2ceb88)
#10 0x00007fc036ccf03d n/a (libcoreclr.so + 0x2cf03d)
#11 0x00007fc036cd2210 n/a (libcoreclr.so + 0x2d2210)
#12 0x00007fc03707592e n/a (libcoreclr.so + 0x67592e)
#13 0x00007fc03729bdf1 start_thread (libc.so.6 + 0x9bdf1)
#14 0x00007fc037320c8c __clone3 (libc.so.6 + 0x120c8c)
Stack trace of thread 171775:
#0 0x00007fc0372a4812 __syscall_cancel_arch (libc.so.6 + 0xa4812)
#1 0x00007fc037298008 __internal_syscall_cancel (libc.so.6 + 0x98008)
#2 0x00007fc037298061 __syscall_cancel (libc.so.6 + 0x98061)
#3 0x00007fc037312701 __open (libc.so.6 + 0x112701)
#4 0x00007fc036f736ff n/a (libcoreclr.so + 0x5736ff)
#5 0x00007fc036f6e717 n/a (libcoreclr.so + 0x56e717)
#6 0x00007fc036f6d885 n/a (libcoreclr.so + 0x56d885)
#7 0x00007fc03707592e n/a (libcoreclr.so + 0x67592e)
#8 0x00007fc03729bdf1 start_thread (libc.so.6 + 0x9bdf1)
#9 0x00007fc037320c8c __clone3 (libc.so.6 + 0x120c8c)
ELF object binary architecture: AMD x86-64What steps can reproduce the bug?
Ask codex to build a dotnet project.
What is the expected behavior?
Codex is able to run a dotnet build command.
Additional information
_No response_
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗