Jai launches strict and casual overlayfs sandboxes for AI agents

• Stanford Secure Computer Systems released jai's official site as a lightweight Linux sandbox for coding agents, and the primary evidence says the core model is mount namespaces plus overlayfs, with private /tmp, a private PID namespace, and a read-only rest of filesystem.
• The launch description exposes three modes, casual, strict, and bare, while the Hacker News thread made the default choice the real point of debate.
• According to the discussion summary, the sharpest objection is not agent escape from the sandbox, but persistent junk written into the project tree, including .pyc, .venv, or git hooks that can execute later outside it.
• One practitioner in the thread described an alternate workflow where the agent edits a full sandboxed copy, then changes move back through diff, apply, and reset commands instead of direct writes.

You can browse jai's homepage, jump to the GitHub repo, and read the HN thread where the interesting bits show up fast: direct project write access, overlayfs edge cases, and a separate complaint that sandboxing in Claude Code has been flaky enough that one commenter now tests restrictions by trying to read a forbidden file.

Jai is pitched as almost no-setup containment: run jai --init, then prefix an agent command like jai codex in the launch description. The packaging is simple enough to feel obvious in retrospect, which is probably why the post took off.

The three modes split cleanly:

• Casual: current working directory writable, home directory on copy-on-write overlay.
• Strict: unprivileged user, empty home.
• Bare: least opinionated mode.

That means jai is not trying to be a full VM or container platform. The core HN summary frames it as a reference point for local agent containment, especially for people who want something lighter than heavier isolation stacks.

The thread's best point is that writable project access may be the dangerous part even if the rest of the machine is locked down. As the discussion recap notes, commenters called out artifacts like .pyc, virtualenvs, and git hooks as persistence paths that can survive the sandbox and fire later in a normal shell.

A deeper thread in the same discussion describes a different handoff model: the agent works inside a full copy of the repo, then only an explicit patch crosses back into the real tree via diff, apply, or reset in the copy-out workflow example. That is a much more opinionated trade, but it is the cleanest alternative surfaced in the launch conversation.

The HN comments also got into implementation detail. One sandbox-tool author asked how jai handles overlayfs limits around reusing an upper layer across multiple mounts, and whether repeated jai bash sessions share or isolate writable home overlays.

The final useful wrinkle came from outside jai itself. Another highlighted comment said sandboxing in Claude Code has been unreliable on both Linux and macOS, and suggested verifying a sandbox by asking the assistant to read something it should not be able to access. That turned a launch thread about a small Stanford tool into a broader reminder that agent sandboxing is still full of sharp edges.