I kinda think having a tool to invoke `bwrap` is overkill for most cases. Applications I want to launch more than once just get a launcher script with `--bind "

I kinda think having a tool to invoke `bwrap` is overkill for most cases. Applications I want to launch more than once just get a launcher script with `--bind "$(dirname "$(realpath "${BASH_SOURCE[0]}")")/FakeHome" ~` or other flags as appropriate. Same for tools that I don't want to install account-wide. Opening a terminal emulator in a `bwrap` sandbox and then using it to launch other applications and create new windows feels like using a VM, except it's all running natively. It's also quite useful to have aliases/functions in `.bashrc` for `--tmpfs ~` or `--bind "$(mktemp -d)" ~`, `--bind "$PWD" "$PWD"`, `--ro-bind "$PWD" "$PWD"`, etc., with varying levels of access to X11/DBus etc. You can quickly test how a code change behaves on a clean install, instantly see what configuration files something uses by running it in a clean sandbox and then running `tree`, and check on your first time using a new program that it isn't going to do anything crazy. I usually use some variant of `sandboxed-dir bash` or `sandboxed-rodir bash`, which I've `alias`ed to `bwrap` with flags as the names describe, whenever I'm about to either run `rm -rf` [1] or otherwise touch files which I'd rather not accidentally destroy. The BubbleWrap sandbox isn't useful just for security, but also for keeping configurations isolated/clean, and protecting against all manner of errors both in software and between the keyboard and chair. --- [1]: `echo rm -rvfi`, actually. See what you're doing before you run it for real, especially if there's a glob in there. And then the `bwrap --dev-bind / / --tmpfs ~ --bind "$PWD" "$PWD" bash` makes absolutely sure you're not going to do anything other than what you said you'd do.