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 multi-tenant isolation with untrusted users → Docker, VM, or a proper container runtime
• 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.

---

Summary

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