Codex CLI shell commands hang indefinitely during bwrap sandbox initialization on autofs-backed mounts

Open 💬 3 comments Opened Apr 28, 2026 by mahendra202602

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

v0.125.0

What subscription do you have?

Corporate

Which model were you using?

gpt-5.5, gpt-5.4

What platform is your computer?

Oracle Linux 8

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

_No response_

What issue are you seeing?

Codex CLI shell commands are hanging indefinitely. Even simple commands like echo test, pwd, date, and ls never return. Instead, they remain as background terminal requests and keep piling up.

This does not appear to be caused by the model loop or by the shell command itself. Investigation suggests Codex is blocking during Bubblewrap sandbox initialization. The sandbox probe appears to run a command similar to:

/usr/bin/bwrap --unshare-user --unshare-net --ro-bind / / /bin/true

That bwrap process then blocks while setting up mounts. The stuck child process was observed in autofs_wait, which suggests it is waiting on an autofs-backed mountpoint encountered while binding the host filesystem.

As a result, Codex becomes unusable because no shell commands complete.

What steps can reproduce the bug?

Run Codex CLI in a Linux environment that has autofs-backed or lazy-mounted workspace paths.
Ask Codex to run a simple shell command, for example:
echo test
date
pwd
ls
Observe that the command does not return.
Run /ps in Codex.
Observe that multiple background terminal requests are still pending and continue to accumulate.
Trace the Codex process or its child processes.
Observe that Codex is waiting on a bwrap sandbox probe, and the bwrap child is blocked during mount setup, with process state showing autofs_wait.

What is the expected behavior?

Codex should complete simple shell commands normally.

If the sandbox cannot be initialized, Codex should fail fast with a clear error message instead of leaving commands running indefinitely in the background.

Ideally, Codex should also avoid blocking forever when bwrap --ro-bind / / encounters an autofs-backed mountpoint.

Additional information

_No response_

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 4 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#19828

Powered by Codex Action

hipotures · 3 months ago

I found the local root cause and a workaround.

The problem was a stale/broken NFS systemd automount at /arch03. I had an /etc/fstab entry like:

192.168.1.102:/arch03 /arch03 ...

After reboot I had not mounted it manually, but it still existed as a systemd autofs trigger:

/arch03 systemd-1 autofs

The NFS server at 192.168.1.102 was powered off / unavailable at the time, so the automount target
could not respond. This meant that any process touching /arch03 could block while the system tried to
resolve/mount the unavailable NFS export.

This was enough for bwrap --ro-bind / / to hit the automount while traversing/bind-mounting /.

Before the fix, this reproduced outside Codex:

time timeout 20 bwrap --unshare-user --unshare-net --ro-bind / / /bin/true

It timed out after 20s.

What helped:

I removed/fixed the stale /arch03 NFS automount entry in /etc/fstab.
I ran sudo systemctl daemon-reload.
I stopped the active stale automount with sudo systemctl stop arch03.automount.

As soon as I stopped arch03.automount, a backlog of previously stuck GUI windows, browser/file-picker
interactions, and Codex sandboxed commands immediately unblocked. The file attachment picker UI also
became responsive right away.

After that, Codex startup/resume returned to normal, and sandboxed Codex commands completed normally
again:

codex resume 019de9ca-8125-7013-b67f-bedd6a28f230: under 1s
/bin/pwd: ~0.001-0.002s
sed -n '1,20p' .gitignore: ~0.001s
git status --short --branch: ~0.012s
findmnt /arch03: returned immediately with no mount found

So in my case this was not Git/shell/model-specific. Codex exposed the issue reliably because its
sandbox path uses Bubblewrap over /, and that interacted badly with a stale NFS automount.

It would still be useful if Codex/Bubblewrap sandbox initialization could fail fast or avoid blocking
indefinitely on stale autofs/NFS mountpoints, because the visible symptom in Codex was that startup/
resume became slow and simple shell commands silently remained pending forever.

This analysis and report were prepared with help from Codex using the gpt-5.5 model with high
reasoning effort.

mahendra202602 · 1 month ago

@etraut-openai Multiple developers in our org are facing this issue. please prioritize it.