Comparison

jai is not trying to replace Docker, bubblewrap, or any other container tool. It fills a different niche: ad-hoc sandboxing of CLI tools on the host machine you already use. This page compares them honestly.

When to use jai

• You want to sandbox an AI agent or CLI tool right now, on your real machine
• You don't want to build an image, write a Dockerfile, or maintain a wrapper script
• You mostly care about preventing filesystem damage and want something better than nothing
• You want your working directory to be live-accessible inside the sandbox

When to use something else

• You need reproducible builds or CI environments → Docker
• You need root privileges for AI agents (e.g., developing/testing system software) → Docker (at a minimum) or a VM
• You need fine-grained seccomp / capability control → bubblewrap or custom container
• You need cross-platform sandboxing → Docker

---

jai vs Docker

Docker is an image-based container runtime. You build an image with your tool installed, then run containers from that image. jai is a host-native sandbox that wraps commands on your existing system.

Rough Docker approximation

The following is a rough approximation of what jai codex does in casual mode. It is not an exact equivalent — Docker does not provide jai's overlay-on-home workflow.

# Very rough approximation — not equivalent
docker run --rm -it \
  --mount type=bind,src="$PWD",dst="$PWD" \
  -w "$PWD" \
  --tmpfs /tmp \
  --tmpfs /var/tmp \
  your-image-with-codex \
  codex

Key differences

	jai	Docker
Setup	jai codex	Build image, configure bind mounts
Home directory	Copy-on-write overlay of your real home	Not available unless manually configured
Current directory	Granted by default	Explicit bind mount required
Host tools	Uses host-installed binaries	Must be installed in the image
Isolation model	Mount + PID namespaces	Full container with cgroups, seccomp, etc.
Bind mount behavior	Writable dirs are explicit	Bind mounts are writable by default and modify host files
Reproducibility	Runs on your host as-is	Fully reproducible via Dockerfile
Image required	No	Yes
Overhead	Minimal	Container + image storage

Docker is the right choice when you need reproducibility, image management, or strong multi-tenant isolation. jai is the right choice when you want to sandbox a command on your existing system with zero setup.

---

jai vs bubblewrap

bubblewrap (bwrap) is a powerful, unprivileged namespace sandbox. It starts from an empty mount namespace and lets you explicitly assemble the filesystem view the sandboxed process sees.

Rough bubblewrap approximation

The following is a rough approximation of what jai codex does. bubblewrap cannot easily set up an overlay filesystem (that would require fuse-overlayfs or root), so this version uses a read-only bind of your home directory instead — it is less capable than jai's overlay.

# Very rough approximation — not equivalent
bwrap \
  --die-with-parent \
  --new-session \
  --unshare-pid \
  --ro-bind / / \
  --proc /proc \
  --dev /dev \
  --tmpfs /tmp \
  --tmpfs /var/tmp \
  --bind "$PWD" "$PWD" \
  --chdir "$PWD" \
  -- codex

Key differences

	jai	bubblewrap
Setup	jai codex	Assemble filesystem from scratch
Home directory	Copy-on-write overlay	Must be explicitly bound (no overlay)
Configuration	Config files, auto-defaults	Flags only (often wrapped in a script)
Overlayfs	Built-in	Not available without fuse-overlayfs
Privilege	Setuid root or sudo	Unprivileged (uses user namespaces directly)
Flexibility	Opinionated defaults	Fully explicit — you control everything
Typical usage	One-liner sandboxing	Flatpak internals, custom sandboxes

bubblewrap is more flexible and works without root. jai is more opinionated and requires far less ceremony for the common case. The 15-flag bwrap invocation that turns into a wrapper script is exactly the friction jai is designed to remove.

---

jai vs chroot

chroot changes the root directory for a process. Linux documents it as not intended to be used as a security mechanism. It is not a serious equivalent to jai or any other sandbox.

• No mount namespace isolation
• No PID namespace isolation
• No credential separation
• Trivially escapable by root
• Requires a full filesystem tree under the chroot path

If you are currently using chroot for sandboxing, any of the other tools on this page would be an improvement.

---

jai vs virtual machines

If you are willing to use a virtual machine, you probably should. A VM gives you a separate kernel and user space, which is a meaningfully stronger boundary than jai or the other host-level tools on this page.

Unlike jai, a VM can safely offer root inside the guest. That makes it the right tool for running less-trusted code, testing system software, or giving an AI agent privileges that would be unacceptable on the host. The tradeoff is that you now have to provision and boot an entire guest OS and decide how host files are shared into it.

Practical setup note

On Linux, a common pattern is to bootstrap a guest image with your distro tooling, boot it with QEMU/KVM, and share a working tree with virtiofs or a network filesystem. That can work well, and it still lets you edit files from the host, but it is much more setup than prefixing a command with jai. That is also close to the author's own workflow when testing jai in a stronger environment; for a concrete Arch Linux example, see Arch VM Setup.

Key differences

	jai	Virtual machine
Setup	jai codex	Provision and boot a guest OS
Isolation boundary	Mount + PID namespaces	Separate kernel and guest OS
Root inside sandbox	No safe equivalent	Yes; guest root is not host root
Host tools	Uses host-installed binaries	Tools live inside the guest
Filesystem workflow	Current directory can be granted directly	Usually shared via virtiofs, 9p, or network copy
System-level testing	Limited to the host environment	Can run init, services, and full distro setup
Overhead	Minimal	Highest on this page: guest memory, disk, and boot time

A VM is the right answer when isolation matters more than convenience. jai is the right answer when you want a much lighter boundary around a host-side CLI workflow you already have.

---

Summary

	jai	Docker	bubblewrap	chroot	Virtual machine
Primary use	Host-native ad-hoc sandbox	Image-based containers	Explicit namespace sandbox	Root directory change	Strong isolation / full guest OS
Setup effort	Minimal	Moderate (images)	Moderate (flags/scripts)	High (full FS tree)	Highest (guest OS)
Overlay home	Yes	No	No (without fuse-overlayfs)	No	N/A (separate guest FS)
Unprivileged	No (setuid/sudo)	Rootless mode available	Yes	No	Usually yes (after setup)
Security model	Casual blast-radius reduction	Strong container isolation	Strong (if configured well)	Not a security mechanism	Separate kernel / guest OS
Linux-only	Yes	No (cross-platform)	Yes	Yes	No