Use cases¶

Scenarios where ixt changes the equation. Each one points to the full step-by-step recipe or command reference for the details.

🕵️ Run a tool you don't fully trust yet¶

You found a promising CLI on GitHub. The author is unknown, the README looks fine, and you want to try running it without handing it your usual shell environment and secret directories.

ixt tool install @some-unknown/cool-cli
ixt tool config cool-cli env base none
ixt tool config cool-cli env allow 'HOME' 'PATH' 'TERM' 'LANG'
ixt tool config cool-cli fs base app-common
ixt tool config cool-cli fs scratch ~/.aws ~/.ssh ~/.config/gh

This protects the runtime command launched through the ixt shim. It does not sandbox package installation or npm lifecycle scripts; use a disposable environment if install-time code is not trusted.

Full recipe · Policy reference

💻 New machine, ready in two commands¶

New laptop. You need your full dev toolchain — Python linters, Node formatters, Rust/Go binaries — repeatable and pin-friendly, without npm -g, without brew, without manual installs scattered across your shell history.

ixt setup path     # add $IXT_HOME/installed/bin to PATH (once)
ixt tool apply          # install everything declared in ixt.toml

One file, three ecosystems. With exact pins, ixt tool apply --remove keeps the machine in sync — anything not listed gets removed.

ixt tool apply reference · ixt.toml format

🤖 Pinned CI — no npm -g, no brew¶

Your CI pipeline installs Python, Node, and binary tools via three different methods. Any of them can pull a different version on a given day, silently. Replace them with one declarative config and one command.

# .gitlab-ci.yml / GitHub Actions
- run: ixt tool apply --remove --yes

--remove prunes anything not declared. --yes confirms those removals in non-interactive CI. CI gets the versions you pinned in ixt.toml; lockfile and strict locked mode are future work.

ixt tool apply reference

🔀 Two versions of the same tool, side by side¶

You're migrating a codebase from ruff 0.5.x to the latest. You need both reachable from the shell — the pinned one for the legacy project, the latest for new work.

ixt tool install ruff                                  # → ruff on PATH
ixt tool install ruff==0.5.7 --slot ruff-old --bare    # env only, no shim
ixt tool config ruff-old expose ruff:ruff-old          # → ruff-old on PATH

Full recipe with ixt.toml

🔬 Audit a tool from a cloned repo¶

Reviewing an open-source project that ships a CLI helper. You want to run it to understand its behaviour — but not before reading every line of its source.

ixt tool install --from ./path/to/project --slot suspect-cli
ixt tool config suspect-cli env base none
ixt tool config suspect-cli env allow 'HOME' 'PATH' 'TERM' 'LANG'
ixt tool config suspect-cli fs base app-minimal
ixt tool config suspect-cli fs rw .

suspect-cli analyze .       # runtime fs view is env_dir + cwd
ixt tool uninstall suspect-cli   # clean removal when done

app-minimal is intentionally strict. Some tools need extra fs ro mounts for interpreters or system files; widen the policy only as needed.

Runtime policy recipe · Policy reference

Policy at a glance¶

The first, fourth, and fifth scenarios above use ixt's runtime policy layer. It is independent from dependency isolation, which ixt always does:

Both policies compose inside the same shim. On Linux, fs policy requires bwrap; without bwrap, env policy is hygiene-only. Network isolation is not implemented yet.

Full policy reference