October 30, 2025
Lock your builds, not your dreams
Show HN: Run a GitHub Actions step in a gVisor sandbox
Dev drops a “CI jail” for GitHub—fans cheer, skeptics yell band‑aid
TLDR: A new GitHub Action puts build steps in a gVisor sandbox to keep untrusted code from messing with your project. Commenters liked the extra safety but argued it’s a stopgap for GitHub’s odd permissions, debating network access, sudo in the sandbox, and whether isolation belongs at the workflow level.
A developer just shipped a GitHub Action that runs your build steps in a gVisor “sandbox”—think: a safe playpen for code—and the comments went feral. The spark? People discovered “read‑only” GitHub workflows still get a token that can write to caches. Cue gasps, memes, and side‑eye. One camp shouted, “Finally, a real seatbelt,” praising a way to test fresh dependencies without inviting supply‑chain disasters. The other camp? Eye‑rolls about “security theater.”
The tool locks commands in a Google‑built sandbox called gVisor. It mirrors a clean Ubuntu setup, keeps your project folder separate by default, and can cut network access. But you must turn off saved checkout credentials, or it will refuse to run—because exposing tokens to untrusted code is a giant nope. Some cheered that changes don’t persist unless you toggle it, while critics raised eyebrows: it still uses the same user with sudo inside the sandbox, which feels like locking the door but leaving the window open.
Drama exploded over whether isolation should happen per step or via fully separate workflows/runners. Performance nerds warned about overhead; pragmatists said any isolation beats vibes‑based security. Jokes flew: “CI jail,” “Schrödinger’s permissions,” and “my dependencies can’t hurt me if they’re in time‑out.” The vibe: cautious applause with spicy skepticism.
Key Points
- •The geomys/sandboxed-step GitHub Action runs commands in a gVisor sandbox to isolate workflow steps.
- •It addresses security issues where read-only GitHub Actions still receive writable cache tokens and all steps share a root-access VM.
- •The sandbox uses a root filesystem similar to Ubuntu 24.04, overlayed access to GITHUB_WORKSPACE (non-persistent by default), and read-only RUNNER_TOOL_CACHE.
- •The Action requires disabling credential persistence in actions/checkout; otherwise it fails to prevent exposing tokens to the sandbox.
- •Configurable inputs include disabling network, persisting workspace changes (unsafe), setting environment variables, and choosing a rootfs image; examples demonstrate Go tests, Staticcheck, and Govulncheck.