v2.2.2

Features

• Add an experimental sandbox action for network-isolated command execution (#155, #156)
  • Buildcage previously only isolated Docker RUN steps; a compromised dependency could still phone home from a plain run: step (npm install, pip install, a test suite, a build script). The new sandbox action wraps any run: command in the same outbound-network allowlist (bridge network, iptables redirect, DNS redirect, SNI/Host-based allowlist proxy) that transparent mode already applies to Docker builds
  • Unlike a Docker build, the command still runs directly on the runner rather than inside a container — so actions/setup-node-installed toolchains, credential-provider actions (e.g. aws-actions/configure-aws-credentials), and actions/cache/$HOME-based caches keep working exactly as they do today, with no image or workflow restructuring needed
  • Also restricts the filesystem to read-only outside $GITHUB_WORKSPACE, $HOME, and /tmp by default (configurable via a new writable input), and is safe to run concurrently across steps via Actions' background/wait/parallel keywords
  • Marked experimental: newer and less battle-tested than the setup/report build-isolation actions — see docs/security.md#sandbox-action for the current threat model and known limitations

Full Changelog: v2.2.1...v2.2.2