Issue Station
Sign In
Tools hereToolbox

codex - ✅(Solved) Fix Codex CLI shell commands hang indefinitely during bwrap sandbox initialization on autofs-backed mounts [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#20017•Fetched 2026-04-29 06:23:42
View on GitHub
Comments
1
Participants
2
Timeline
7
Reactions
0
Author
mahendra202602mahendra202602
Participants
github-actions[bot]github-actions[bot]mahendra202602mahendra202602
Timeline (top)
labeled ×4commented ×1cross-referenced ×1unlabeled ×1

Error Message

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

Root Cause

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:

Fix Action

Fixed

PR fix notes

PR #20111: [codex] Bound advisory system bwrap startup probe

Description (problem / solution / changelog)

Why

Linux startup runs an advisory system bwrap warning probe on each launch. On hosts with NFS or autofs mounts, its --ro-bind / / probe can take tens of seconds before Codex prints anything, matching #19828. Because this probe only decides whether to surface a warning, it should not be allowed to stall startup.

Relevant pre-change path: codex-rs/sandboxing/src/bwrap.rs

What changed

  • Bound the advisory system bwrap probe to 500 ms.
  • Preserve the existing warning behavior when bwrap promptly reports a known user-namespace failure.
  • Kill and reap the probe child on timeout, then suppress the advisory warning instead of blocking startup.
  • Add regression coverage with a deliberately slow fake bwrap process.

Security

This only bounds the advisory startup probe. It does not change the command execution path or add a fail-open sandbox fallback. The related command-side hang in #20017 remains separate from this PR.

Verification

  • Added system_bwrap_probe_times_out_without_reporting_a_warning.
  • cargo test -p codex-sandboxing
  • cargo clippy -p codex-sandboxing --all-targets -- -D warnings

Fixes #19828 Related: #20017

Changed files

  • codex-rs/sandboxing/src/bwrap.rs (modified, +45/-6)
  • codex-rs/sandboxing/src/bwrap_tests.rs (modified, +20/-0)
RAW_BUFFERClick to expand / collapse

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

extent analysis

TL;DR

The most likely fix is to modify the Codex CLI configuration to avoid using autofs-backed or lazy-mounted workspace paths, or to implement a timeout for the bwrap sandbox initialization.

Guidance

  • Investigate the autofs configuration on the Oracle Linux 8 system to see if there are any mounts that can be converted to non-autofs mounts to prevent the blocking issue.
  • Consider adding a timeout to the bwrap command to prevent it from hanging indefinitely, for example: bwrap --unshare-user --unshare-net --ro-bind / / /bin/true --timeout 10.
  • Verify that the issue is specific to the Codex CLI and not a general problem with the bwrap command by running the bwrap command directly in the terminal.
  • Check if there are any existing issues or workarounds in the Codex CLI documentation or community forums related to autofs-backed mounts.

Example

No code snippet is provided as it is not clearly supported by the issue.

Notes

The root cause of the issue appears to be related to the interaction between the bwrap command and autofs-backed mounts. However, without further information about the specific autofs configuration and the Codex CLI implementation, it is difficult to provide a more specific solution.

Recommendation

Apply a workaround by modifying the autofs configuration or adding a timeout to the bwrap command, as the root cause of the issue is related to the interaction between bwrap and autofs-backed mounts, and a fix may require changes to the Codex CLI or the underlying system configuration.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#conversation history#tool integration#LLM response#prompt template#agent execution

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - ✅(Solved) Fix Codex CLI shell commands hang indefinitely during bwrap sandbox initialization on autofs-backed mounts [1 pull requests, 1 comments, 2 participants]