[thliebig]

What

A new --dev-bind PATH option and an EXTRA_DEV_BINDS config hook, which pass a host device into the sandbox with --dev-bind-try.

Why

The sandbox gets a minimal /dev from --dev /dev, and the only way to add to it is --bind. bwrap mounts a plain bind nodev, so a device passed that way shows up inside but cannot be opened:

$ ai-bwrap bash --bind /dev/kfd -- -c 'ls /dev/kfd; : < /dev/kfd'
/dev/kfd
/usr/bin/bash: line 1: /dev/kfd: Permission denied

That rules out anything that needs a GPU. I ran into it trying to build and test HIP code (AMD, ROCm) from inside the sandbox.

Scope

• The device binds are appended after --dev /dev, like the other extra binds, so they land on top of it. They are also added to the overlay mask list, as the other extra binds are.
• There is no GPU-specific option. A GPU also needs /sys and, for ROCm, /opt/rocm; the existing read-only binds cover those. The README shows the config for an AMD GPU as an example:

  EXTRA_DEV_BINDS+=( /dev/kfd /dev/dri )
  EXTRA_RO_BINDS+=( /sys /opt/rocm )

• README: option table, a row in "What the sandbox blocks", and a security note on passing devices. --help and the changelog are updated with it.

Tests

• 30-options: --dev-bind without a value is an error; the option becomes a device bind.
• 50-config: EXTRA_DEV_BINDS reaches the sandbox.
• 60-confinement: a real sandbox with --dev-bind /dev/null writes to it, which fails with a plain bind.

shellcheck ai-bwrap scripts/screenshots.sh is clean and ./tests/run.sh passes locally (91 passed, 3 skipped for agents that are not installed).

AI disclosure

This change, including the tests, docs and this description, was generated with Claude Code (Claude Opus 5.5) and reviewed by me. The failing --bind /dev/kfd example above is from my own machine.

🤖 Generated with Claude Code