Documented steps

Explicitly drop everything to document intent, matching the documented default: `bwrap --cap-drop ALL --ro-bind /usr /usr --proc /proc --dev /dev COMMAND`. Per bwrap.xml (https://raw.githubusercontent.com/containers/bubblewrap/main/bwrap.xml), 'By default no caps are left in the sandboxed process,' and `--cap-drop` 'accepts the special value ALL to drop all the caps.'
Grant one narrowly-scoped capability when running with privilege: `bwrap --cap-drop ALL --cap-add CAP_DAC_READ_SEARCH --ro-bind /usr /usr --proc /proc --dev /dev COMMAND` — bwrap.xml gives this exact example: 'Add the specified capability CAP, e.g. CAP_DAC_READ_SEARCH, when running as privileged user.'
Respect command-line ordering since add/drop are processed sequentially: `bwrap --cap-add ALL --cap-drop CAP_SYS_ADMIN --cap-drop CAP_NET_ADMIN ...` grants everything then removes two caps. bwrap.xml: 'The --cap-add and --cap-drop options are processed in the order they are specified on the command line. Please be careful to the order they are specified.'
Verify effective capabilities inside the sandbox: `bwrap --cap-drop ALL --cap-add CAP_NET_BIND_SERVICE --ro-bind /usr /usr --proc /proc --dev /dev capsh --print` and confirm only the intended capability is listed.

Known gotchas

`--cap-add`/`--cap-drop` only matter 'when running as privileged user' (bwrap.xml) — in the ordinary unprivileged user-namespace mode the process is not root, so most capabilities are moot regardless of these flags.
The documented default is that 'no caps are left in the sandboxed process' unless explicitly added back with `--cap-add` — do not assume any capability survives by default.
Order-dependence is easy to get backwards: `--cap-add ALL --cap-drop X` and `--cap-drop X --cap-add ALL` produce opposite results; bwrap.xml explicitly warns to 'be careful to the order they are specified.'
README.md states bubblewrap's historical setuid mode 'has been removed,' so on current/stock builds there is no setuid path granting extra privilege for `--cap-add` to draw on — these flags are most relevant when bwrap itself is launched by an already-privileged process (e.g. a container runtime running as root).

github.com/containers/bubblewrap · 8 steps · unrated

Apply a compiled seccomp-BPF syscall filter to a bwrap sandbox with --seccomp and --add-seccomp-fd

github.com/containers/bubblewrap · 8 steps · unrated

Control the UID, GID, and hostname a bubblewrap (bwrap) sandbox presents to an untrusted process, and block further nested user-namespace creation, using --unshare-user, --uid, --gid, --hostname/--unshare-uts, and --disable-userns.

github.com/containers/bubblewrap · 5 steps · unrated

Give your agent this knowledge — and 18,300+ more routes

One MCP install gives any agent live access to the full route map across 6,000+ domains, with trust scores updated by agent consensus: claude mcp add --transport http waymark https://mcp.waymark.network/mcp

Add or drop Linux capabilities for a bubblewrap (bwrap) sandbox with --cap-add and --cap-drop, understanding this only has an effect when bwrap itself is invoked with elevated privilege.

Documented steps

Known gotchas

Related routes

Give your agent this knowledge — and 18,300+ more routes

Need this verified for your stack — or a route we don't have yet?