Feature request: sandbox GPU/CUDA access via --dev-bind for /dev/nvidia* device nodes

Summary

The Linux sandbox (bubblewrap) cannot expose GPU/CUDA devices even when /dev/nvidia* paths are added to sandbox.filesystem.allowWrite in settings. This makes it impossible to run CUDA code (e.g. torch.cuda.is_available(), nvidia-smi) in sandboxed Bash commands.

Root cause

The sandbox runtime uses --dev /dev + --bind when constructing the bwrap command. --dev mounts an isolated tmpfs with nodev, and --bind onto it does not grant working device access (NVML returns Insufficient Permissions). GPU device nodes require --dev-bind, which the sandbox runtime never emits.

Minimal reproduction:

# Fails (plain --bind after --dev) — what Claude sandbox currently does
bwrap --ro-bind / / --dev /dev --proc /proc \
  --bind /dev/nvidia0 /dev/nvidia0 \
  --bind /dev/nvidiactl /dev/nvidiactl \
  --bind /dev/nvidia-uvm /dev/nvidia-uvm \
  nvidia-smi -L
# -> "Failed to initialize NVML: Insufficient Permissions"

# Works (--dev-bind)
bwrap --ro-bind / / --dev /dev --proc /proc \
  --dev-bind /dev/nvidia0 /dev/nvidia0 \
  --dev-bind /dev/nvidiactl /dev/nvidiactl \
  --bind /dev/nvidia-uvm /dev/nvidia-uvm \
  nvidia-smi -L
# -> GPU 0: Tesla T4 (UUID: ...)

Proposed solution

Add a settings key (e.g. sandbox.allowGpu: true, or extend sandbox.filesystem.allowWrite to use --dev-bind for paths under /dev/) that causes the sandbox runtime to use --dev-bind instead of --bind for NVIDIA device nodes.

Suggested device nodes to bind when enabled:

• /dev/nvidia0 … /dev/nvidiaN (per-GPU)
• /dev/nvidiactl
• /dev/nvidia-uvm
• /dev/nvidia-uvm-tools
• /dev/nvidia-modeset
• /dev/nvidia-caps

Use case

ML/AI research workflows that run GPU-accelerated Python (PyTorch, JAX, RAPIDS, etc.) inside sandboxed Claude Code sessions. Without this, every GPU command requires dangerouslyDisableSandbox: true, which disables all sandbox protections.

Workaround

Use dangerouslyDisableSandbox: true per command, or disable the sandbox entirely.