Download ai-jail 2.9.0

A feature release: one narrow way to reach a host loopback service without --network, Devin launching pre-authenticated with its installation protected, Codex starting under macOS Seatbelt again, and two correctness fixes.

Backward compatible: every pre-2.9.0 .ai-jail keeps working.

Added

• --forward-port PORT relays one host loopback port into the sandbox (#164, closes #158). Without --network the sandbox has its own loopback, so a local MCP server, an editor's IDE socket, or a dev database on the host's 127.0.0.1 was unreachable, and --network — the whole host network back on — was the only way out. --forward-port (repeatable; forward_ports in the global config) relays exactly that port through a per-launch Unix socket onto the sandbox's own loopback: the private network namespace stays up and every other host port stays unreachable. It composes with filtered egress and --lockdown, is refused with --network, for ports below 1024, and outside Linux; the agent starts only once every forward bridge is listening, and a bridge that cannot bind fails the launch. At most 256 relays run per forward. A forwarded port is trusted in full — no allowlist, inspection, or audit record — and only the CLI and global config can open one: a project .ai-jail cannot, and auto-save and --init never write one. The host side dials 127.0.0.1 first and falls back to [::1] for IPv6-only services. Thanks @lucascouts.

• Devin launches pre-authenticated with its managed installation protected (#163). ai-jail devin now shares the existing devin state roots under $XDG_DATA_HOME and $XDG_CONFIG_HOME (defaults ~/.local/share and ~/.config) read-write — login, settings, and session history — while the self-managed CLI installation under devin/cli stays pinned: cli is a mountpoint so it cannot be renamed, and cli/_versions is read-only on both backends, with the mutable current selector write-denied by node on macOS. A present-but-invalid installation falls back conservatively (read-only data); an absent cli (an external install) shares state without installation rules. XDG overrides are resolved physically — symlinked bases and .. never collapse lexically — and Devin's API host server.codeium.com joins the default filtered-egress table, unioned with explicit --allow-host as for the other agents. Thanks @lhzapata.

• chatgpt.com joins Codex's default filtered egress (#168). Workspace- backed Codex needs it alongside api.openai.com for ChatGPT OAuth routing; API-key traffic alone needed only the API host.

Fixed

• Codex starts again under macOS Seatbelt (#168). Codex 0.162.1 calls the setuid /bin/ps to validate its managed app-server, which Seatbelt refuses to exec. Non-lockdown Codex launches now get a private, unprivileged ps shim (this binary, symlinked into the session temp dir) that answers only that one PID/start-time query, reading no command lines or other host process data. The shim also reaches the canonical executable through symlinked launch paths, and Codex's app-server gets the macOS services it needs (CFPreferences shared memory, cfprefsd/trustd lookups) scoped to Codex with --no-agent-state opting out. Thanks @andrelramos.

• --x11 alone passes X11 through, as documented (#167). All X11 handling lived behind --display, so --x11 without it gave the sandbox no DISPLAY and no /tmp/.X11-unix — silently, not even under --verbose — although every doc describes X11 as its own opt-in. Each flag now gates its own protocol; --lockdown still turns both off. Thanks @diogochaves.

• Auto-save no longer writes opt-ins an untrusted project file would refuse (#166). One ai-jail --pictures --no-network true was enough to get project .ai-jail pictures ignored because it weakens the baseline sandbox on every later run: auto-save wrote CLI capability opt-ins into the project file that the untrusted merge then rejects. Auto-save now writes exactly what the project layer's own load accepts (tightening values kept; trusted projects unchanged), so a saved file never warns on reload, and files polluted by earlier versions clean themselves up. Thanks @diogochaves.

Documentation

• Host-side git and masks noted as residual risks (#165). The writable project includes .git/, which host-side git trusts: a program named in .git/config (for example core.fsmonitor) or dropped into .git/hooks/ runs outside the sandbox on the next matching host git operation. The note says what closes it today (--lockdown, --map .git) and that --mask/--deny-path change only what the sandbox sees — host-side helpers acting for the agent still read the real files.

Checksums (SHA256)

9a6120a67c0e8d14dd57b06c4b003c28b0e565dd1c8632bf998b3c7f878872a9  ai-jail-linux-x86_64.tar.gz
62b3ece819a899760ef41fa04ab026729703cc388fde486e54b177a7eb253f37  ai-jail-macos-aarch64.tar.gz

Install

brew tap akitaonrails/tap && brew install ai-jail
yay -S ai-jail-bin
cargo install --locked ai-jail

A follow-up to the v2.8.0 agent-API-egress default: an explicit --allow-host list no longer cuts off the agent's own API.

Backward compatible: every pre-2.8.1 .ai-jail keeps working.

Fixed

• The default agent API host is unioned with --allow-host, not suppressed by it (#156). In v2.8.0 the automatic API-host default only applied when --allow-host was empty, so ai-jail --allow-host github.com claude reached github.com but silently dropped api.anthropic.com and left Claude unable to talk to its API — surprising, and inconsistent with the toolchain-registry default, which already unions onto an explicit --allow-host list. The agent default now behaves the same: adding a host extends what the agent can reach instead of cutting off its own API, so ai-jail --allow-host github.com claude reaches github.com and api.anthropic.com. Neither automatic default (agent API host or registry hosts) is gated on --allow-host being empty any more — only on the asserted network posture.

  The verbatim "only this list, nothing automatic" mode is unchanged and explicit: ai-jail --no-network --allow-host github.com claude composes to filtered egress with github.com only. --no-network sets the posture, which disables both automatic defaults, while a non-empty allow-list keeps egress filtered rather than fully offline. --network and --lockdown keep their existing behavior; the sandbox stays deny-by-default throughout.

Checksums (SHA256)

9c5e41b59be8fd65f239252f8d2e03f16a806d76c090bd256948b452b350710b  ai-jail-linux-x86_64.tar.gz
ff1f076b2ed8cedffaa78d02c3c5014ed9e3424f70a5f06145475424ce79cedb  ai-jail-macos-aarch64.tar.gz

Install

brew tap akitaonrails/tap && brew install ai-jail
yay -S ai-jail-bin
cargo install --locked ai-jail

A bare ai-jail claude (or codex/gemini/grok) now reaches its model API out of the box, and Kiro CLI joins the recognized agents. macOS Codex and Claude logins are fixed, and the PTY no longer stalls launchers that probe the cursor position.

Backward compatible: every pre-2.8.0 .ai-jail keeps working.

Added

• Each known agent's own API host is default-allowed (#156). With no network posture and no explicit --allow-host list, a bare launch of a known API agent now receives filtered egress to that agent's own documented API host — claude → api.anthropic.com, codex → api.openai.com, gemini → generativelanguage.googleapis.com, grok → api.x.ai — so it reaches its model API without opening the whole network. Deny-by-default still holds: only the agent's single functional API host is added (never a telemetry host), and an explicit --allow-host set is used verbatim instead. Not Linux-only — macOS filtered egress is a seatbelt loopback rule, so it applies there too — and gated on the same unprivileged-netns probe as registry egress, staying fully offline when that is unavailable. --no-network, --network, a browser launch, and --lockdown all keep their existing semantics. Reshaped from a Claude-only proposal; thanks @andrelramos.
• Kiro CLI is recognized for agent-state (#155). Its login/session state (~/.kiro plus ~/.local/share/kiro-cli on Linux, ~/Library/Application Support/kiro-cli on macOS) is mounted under private home on both backends, and kiro-cli is listed among the positional presets. Thanks @JuanMCanchala.

Fixed

• macOS: Claude Code Keychain login and the Codex control socket (#154). The seatbelt profile now preserves Claude Code's Keychain-stored auth and allows the Codex app-server control socket, so both launch logged-in on macOS. Thanks @andrelramos.
• Cursor-position requests are answered from the vt100 screen (#159). A launcher that emits a Device Status Report (cursor-position query) no longer stalls waiting for a reply: ai-jail answers it from the virtual terminal's own cursor when the child is on the primary screen. Thanks @enosteteo.

Internal

• Hardened the filtered-egress proxy against descriptor exhaustion and fixed a lock race in its tests (#157, thanks @lucascouts). Widened a flaky gh-token-lookup test timeout.
• Assessed Microsoft LiteBox for a future Windows port (not a fit; a Windows backend would use WSL2 or a native AppContainer/Job Objects sandbox).

Checksums (SHA256)

4965827929a1366f75747e87116cee6a5eb3fc13d310d180f3c923dca7df6a6c  ai-jail-linux-x86_64.tar.gz
52fd5f693b049c1b1956a2030c4768d9ca6bcbe12df6547434df941c7ab9090b  ai-jail-macos-aarch64.tar.gz

Install

brew tap akitaonrails/tap && brew install ai-jail
yay -S ai-jail-bin
cargo install --locked ai-jail

Two contributed fixes land this release: --github now works when your gh token lives in the system keyring, and the private-home command exemption no longer breaks symlink-following launchers.

Backward compatible: every pre-2.7.0 .ai-jail keeps working.

Added

• --github forwards a keyring-stored gh token (#153). --github already mounts ~/.config/gh read-only, but gh auth login stores the token in the system keyring by default, so a jailed gh found the account but no credential. With --github, ai-jail now runs gh auth token --hostname github.com on the host (no shell, 5s timeout, validated output) and forwards the result as GH_TOKEN for that launch only. The value rides the #147 --args memfd, so it never touches argv, disk, or a saved .ai-jail; --dry-run never fetches it; an explicit/host GH_TOKEN/GITHUB_TOKEN short-circuits the lookup; and the capability stays opt-in, monotonic (a project .ai-jail cannot enable or steer it), and disabled under --lockdown. No keyring or D-Bus access from inside the jail. Thanks @miguins.
• prime-agent is recognized for agent-state (#152). Its auth/session state under ~/.prime/agent is mounted (bwrap + seatbelt), never the whole ~/.prime — the sibling config.json holding the prime CLI's API key stays hidden.

Fixed

• Private-home command exemption preserves symlink chains (#152). The exemption bound the launcher's path with --ro-bind, which flattened symlink hops, so a symlink-following launcher (e.g. bun's app-root heuristic, which looks for package.json in the dirname of the resolved executable) crashed with ENOENT. Each symlink hop is now recreated inside the sandbox with --symlink using the verbatim host target text; only the terminal real path is bind-mounted read-only. Relative hops are lexically normalized so no collected mount path carries ... The #138 dedup (skip paths under an already-bound dir) is preserved. Thanks @jadsongmatos.

Checksums (SHA256)

b8b5ef75027d0d6bd9d2d2f2cfc20e83a4f0916e7237604fea3b81f85eaee067  ai-jail-linux-x86_64.tar.gz
3c6a4cc41212f337ba72e1895b11dd10ae620b5bb86d384919a7e29aeb8ff0ba  ai-jail-macos-aarch64.tar.gz

Install

brew tap akitaonrails/tap && brew install ai-jail
yay -S ai-jail-bin
cargo install --locked ai-jail

A reliability fix for filtered egress. Transient listener failures no longer disable proxy access for the remainder of a sandbox session.

Backward compatible: every pre-2.6.4 .ai-jail keeps working.

Fixed

• Filtered egress recovers after a transient accept() failure (#151). The supervisor's TCP and Unix proxy listeners and the in-sandbox bridge used iterator loops that ended permanently on the first failed accept. Descriptor exhaustion or an aborted client could therefore leave every later connection refused until the sandbox exited. All three listeners now retry after a bounded delay, avoiding a busy loop while preserving the session. Internal bridge retries also inherit --exec quiet mode.

Documentation

• Corrected two references in the v2.6.1 notes that were internal ai-memory inbox identifiers rather than GitHub issue numbers.

Checksums (SHA256)

7749b73435686b783567bf0427f7cdf4faf7783ac31b1d590d0454048b243d4b  ai-jail-linux-x86_64.tar.gz
2563884af5c29e761612e38f50c970e51d0a94e64ed59c167a327b886bffc169  ai-jail-macos-aarch64.tar.gz

Install

brew tap akitaonrails/tap && brew install ai-jail
yay -S ai-jail-bin
cargo install --locked ai-jail

A maintenance release. The sandbox binary is unchanged from v2.6.2; this release only fixes building ai-jail from source under Nix on recent kernels.

Backward compatible: every pre-2.6.3 .ai-jail keeps working.

Fixed

• nix build no longer fails its checkPhase on kernels with Landlock ABI ≥ 6 (Linux ≥ 6.12). Nix's builder hardening wraps Linux builds in an outer, scope-only Landlock layer; under stacked-layer semantics, as soon as ai-jail's own filesystem ruleset makes the domain filesystem-applicable, the outer layer (which grants no REFER) denies every cross-directory rename with EXDEV, so the landlock_allows_cross_dir_rename_* integration tests failed and landlock_denies_rename_out_of_readonly_map passed vacuously. The REFER tests now run a probe outside the jail and skip themselves when an outer Landlock domain denies reparenting to a nested ruleset, since ai-jail's inner REFER grants are unmeasurable there. On an ordinary host (no outer Landlock) the tests still run and pass as before. Thanks to @pqitr (#150).

Checksums (SHA256)

31c44e8f4da78bc4bad7b4d0ba4e0c2578eec8035594e13744764c6b108eef95  ai-jail-linux-x86_64.tar.gz
dc466ba94f99ab179f525e0d5749dbed7d81c7832c677d090fb5745a78365848  ai-jail-macos-aarch64.tar.gz

Install

brew tap akitaonrails/tap && brew install ai-jail
yay -S ai-jail-bin
cargo install --locked ai-jail