Allow GPU access inside sandbox

met the same issue

I'm also interested in this.

+1

i found when i pass --dangerously-bypass-approvals-and-sandbox, it can use GPU in docker.

+1

same issue for me but --dangerously-bypass-approvals-and-sandbox (thanks @L1aoXingyu) works on campus HPC cluster

+1

+1

@L1aoXingyu Thanks！

Similar issue on Windows and WSL using the VSCode extension. I'm not a security expert so it's not clear to me why it can't access GPU resources without being in "full access" mode. I still want to limit its access to files on my computer, as I have sensitive data, but I want it to be able to autonomously run ML experiments using my local GPU.

(One especially confusing aspect is the fact that in non-full-access mode, it can successfully run nvidia-smi and see that the GPU device exists, but torch.cuda.is_available() == False.)

i found when i pass --dangerously-bypass-approvals-and-sandbox, it can use GPU in docker.

Dangerous bypass should not be required for GPU access -- ideally a flag should be used when calling just like how websearch has one.

I hit the same issue and agree - it should be possible to allow GPU access while still restrict other access.

Totally agree. Should have a command maybe called "enable_GPUs"

really need this feature!!!!

This limitation is due to the sandbox policy. To make this work, we'd need to determine which system call(s) need to be allowed to avoid blocking access to GPU functionality. If someone in the community is willing to investigate this, it would help accelerate this feature.

Not sure about the seccomp part (never used it), but for landlock you just need to add an exception path to /dev/gpu_name that allows it to write to it (LANDLOCK_ACCESS_FS_WRITE_FILE). The exception path support is relatively new in landlock, but as long as your linux distro version is somewhat recent it should be there (works for me on Ubuntu 22).

This is not a "feature" , it is a lack of capability. Claude Code runs my GPU and never report any "access denied" errors

The way I've currently gotten around this in VSCode is to create a devcontainer and then run ChatGPT in full access mode inside of that container. That way, the access is properly scoped, and GPU access is still enabled.

Run Codex with sandbox disabled:

codex --sandbox danger-full-access

or a “nuclear” option that bypasses both approvals and sandboxing:

codex --dangerously-bypass-approvals-and-sandbox
# alias: codex --yolo

@per-mathisen-arm, I've created a PR that implements your suggested approach. Would you be willing to do a code review? Even better if you or someone else in this thread would be willing to do a local build of the change and verify that it allows you to access the GPU.

This still seems to be a problem. It is impossible to use codex for ML programming right now without disabling the sandbox.

There are security concerns about giving access to the GPU from within the sandbox. We're thinking about ways we can mitigate this or expose finer-grained sandbox policy knobs that allow users to enable GPU access within the sandbox if they're OK with the associated risks.

There are security concerns about giving access to the GPU from within the sandbox. We're thinking about ways we can mitigate this or expose finer-grained sandbox policy knobs that allow users to enable GPU access within the sandbox if they're OK with the associated risks.

Finer grain sandbox policy knobs would be nice. Currently, really your only choice is either sandbox on (impossible to do GPU programming) or sandbox off (which defeats the whole purpose of the sandbox).

I currently use

[sandbox_workspace_write] writable_roots = [ "/dev" ]

in my config.toml - it is pretty large hole in the sandbox, but much better than not having any sandbox. You can narrow this down to the specific dev node(s) used by your GPU driver. This is all assuming you use Linux, of course.

I currently use > [sandbox_workspace_write] > writable_roots = [ "/dev" ] in my config.toml - it is pretty large hole in the sandbox, but much better than not having any sandbox. You can narrow this down to the specific dev node(s) used by your GPU driver. This is all assuming you use Linux, of course.

will try this out.

I can reproduce a consistent CUDA failure inside Codex sandbox on Linux, while CUDA works fine outside.

• codex-cli 0.98.0
• Driver: 580.119.02
• PyTorch: 2.9.1+cu128

Repro:

Outside Codex (normal shell):
python3 - <<'PY'
import torch
print("torch", torch.__version__)
print("is_available", torch.cuda.is_available())
if torch.cuda.is_available():
x = torch.zeros(1, device="cuda")
print("ok", x)
PY

Output:
torch 2.9.1+cu128
is_available True
ok tensor([0.], device='cuda:0')

Inside Codex with sandbox_mode="workspace-write":

• torch 2.9.1+cu128
• torch.cuda.is_available() == False
• CUDA init fails: cudaGetDeviceCount -> Error 304 (cudaErrorOperatingSystem: “OS call failed or operation not supported on this OS”)
• Minimal smoke test (torch.zeros(..., device="cuda")) fails with the same error.

Note: nvidia-smi works inside the same Codex session and shows the GPU as present, but CUDA runtime initialization from within the Python process fails.

I also tried the common “/dev workaround” (ensuring /dev/nvidia* is visible / accessible inside the sandbox), but it does not help: PyTorch still fails during CUDA initialization with Error 304.

I can reproduce a consistent CUDA failure inside Codex sandbox on Linux, while CUDA works fine outside. codex-cli 0.98.0 Driver: 580.119.02 PyTorch: 2.9.1+cu128 Repro: Outside Codex (normal shell): python3 - <<'PY' import torch print("torch", torch.version) print("is_available", torch.cuda.is_available()) if torch.cuda.is_available(): x = torch.zeros(1, device="cuda") print("ok", x) PY Output: torch 2.9.1+cu128 is_available True ok tensor([0.], device='cuda:0') Inside Codex with sandbox_mode="workspace-write": torch 2.9.1+cu128 torch.cuda.is_available() == False CUDA init fails: cudaGetDeviceCount -> Error 304 (cudaErrorOperatingSystem: “OS call failed or operation not supported on this OS”) Minimal smoke test (torch.zeros(..., device="cuda")) fails with the same error. Note: nvidia-smi works inside the same Codex session and shows the GPU as present, but CUDA runtime initialization from within the Python process fails. I also tried the common “/dev workaround” (ensuring /dev/nvidia is visible / accessible inside the sandbox), but it does not help: PyTorch still fails during CUDA initialization with Error 304.

yeah, I opened /dev and nvidia-smi works however cuda initialization in pytorch still fails. It likely can see the nodes but not interface with them

For me "/dev" workaround was fine for one project, but in another torch didn't see the card.

The fix for me was upgrading the nvidia drivers, giving codex write permission to the uv cache dir and then having codex run code through uv, in addition to the "/dev" workaround.

i found when i pass --dangerously-bypass-approvals-and-sandbox, it can use GPU in docker.

thanks，but it is very dangerous

Still an issue on the latest versions. I will see if there is a way to patch this and then submit a PR, as it seems silly to me that hardware pass-through should require dangerously escalating permissions elsewhere.

This works, and I feel better about it than allowing all of /dev. It seems to me that it might be impossible to scope the sandbox hole any smaller than this:

[sandbox_workspace_write]
writable_roots = [ "/dev/nvidia", "/dev/dri" ]

thanks its work

Wit
@.***

Any safe solutions if you are working on a hpc cluster? I don't think i should be giving codex writable permissions to the /dev dir (it probably would get denied)

After the latest update it causes a sandbox error to have the config I proposed earlier:

[sandbox_workspace_write]
writable_roots = [ "/dev/nvidia", "/dev/dri" ]

really need this feature

The inability to allow GPU access within the sandbox is a very strange state of affairs. Does anyone have an explanation other than Ernestine's response to customers: "We don't care. We don't have to. We're The Phone Company."?