codex - 💡(How to fix) Fix [Bug] GPU access blocked in Linux sandbox on WSL2: /dev/dxg not exposed by bubblewrap [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#22469Fetched 2026-05-14 03:35:28
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Author
Participants
Timeline (top)
closed ×2labeled ×2commented ×1reopened ×1

Root Cause

Root Cause

Fix Action

Fix / Workaround

Workaround

RAW_BUFFERClick to expand / collapse

Title: [Bug] GPU access blocked in Linux sandbox on WSL2: /dev/dxg not exposed by bubblewrap

Body:

Summary

When running shell commands inside the Codex Linux sandbox (bubblewrap) on WSL2, any process that uses NVML (e.g., nvidia-smi, PyTorch CUDA, etc.) fails with:

Failed to initialize NVML: GPU access blocked by the operating system

Environment

  • Codex version: 0.130.0
  • OS: WSL2 (kernel 6.6.114.1-microsoft-standard-WSL2)
  • GPU: NVIDIA GeForce RTX 4060
  • NVIDIA driver (Windows host): 591.86
  • WSL nvidia-smi version: 590.57

Root Cause

Codex launches bubblewrap with --dev /dev, which replaces the container's /dev with a minimal set:

/dev/null, /dev/zero, /dev/full, /dev/random, /dev/urandom, /dev/tty

On WSL2, GPU access goes through /dev/dxg (the DirectX Graphics kernel interface) — there are no /dev/nvidia* device nodes. Even though the host filesystem is bound via --ro-bind / / first, the subsequent --dev /dev overwrites /dev and hides /dev/dxg, making it inaccessible inside the sandbox.

Confirmed via strace:

execve("/usr/bin/bwrap", ["bwrap", "--new-session", "--die-with-parent", "--ro-bind", "/", "/", "--dev", "/dev", ← hides /dev/dxg "--unshare-user", "--unshare-pid", "--unshare-net", "--proc", "/proc", "--", "codex-linux-sandbox", ...], ...)

Reproduction

codex sandbox linux -- nvidia-smi
# → Failed to initialize NVML: GPU access blocked by the operating system

Workaround

Setting sandbox_mode = "danger-full-access" in ~/.codex/config.toml bypasses
the user namespace / --dev restriction and allows GPU access.

sandbox_mode = "danger-full-access"

However, this significantly weakens sandboxing.

Proposed Fix

When Codex detects WSL2 (e.g., by checking /proc/version for microsoft or
WSL2, or by detecting /dev/dxg), add a --dev-bind after --dev /dev in the
bubblewrap command to expose the device:

// in linux-sandbox/src/bwrap.rs (approximate)
if Path::new("/dev/dxg").exists() {
    bwrap_args.push("--dev-bind");
    bwrap_args.push("/dev/dxg");
    bwrap_args.push("/dev/dxg");
}

This would restore GPU access inside the sandbox without requiring danger-full-access.

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…

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 - 💡(How to fix) Fix [Bug] GPU access blocked in Linux sandbox on WSL2: /dev/dxg not exposed by bubblewrap [1 comments, 2 participants]