cargox
runs Rust binaries on demand, installing them automatically if necessary.
It mirrors the convenience of npx
for the Cargo ecosystem while prioritising
cargo-binstall
to download prebuilt executables whenever possible.
We recommend installing cargo-binstall as well, this significantly speeds up
use of cargox
:
cargo install cargo-binstall
cargo binstall cargox-cli
If you don’t want that then you can just cargo install cargox-cli
.
- Executes
crate[@version]
binaries, installing them on demand. - Prefers
cargo-binstall
for fast installs falling back tocargo install
. - Passes through additional arguments to the invoked binary via
--
.
cargox <crate[@version]> [--] [binary-args...]
Examples:
# Run the latest bat that is installed or installing the latest bat if necessary
$ cargox bat ./README.md
$ cargox bat@latest ./README.md
# If the installed bat is old we only check for newer if you do this.
# This is how every foo*x* tool works. We are not being different.
# Install and run a pinned version
$ cargox [email protected] check
# Force a reinstall, building from source instead of using cargo-binstall
$ cargox --force --build-from-source cargo-nextest
# ^^ shorter: cargox -fs cargo-nextest
Tip
- Arguments before the first positional are passed to
cargox
. - Arguments after the positional argument are passed to the invoked binary.
- You can use
--
if necessary to define this separation point.
--bin <name>
: choose a specific binary when a crate exposes several.-f
,--force
: reinstall even if the binary already exists onPATH
.-q
,--quiet
: suppress installer output (still prints a short status line).-s
,--build-from-source
: build from source usingcargo install
instead ofcargo-binstall
.
Every binary installed by cargox
is stored with an explicit version suffix. For example, running cargox [email protected]
produces bin/bat-0.24.0
under the install root. When you invoke cargox bat
without a version, the newest installed version is selected automatically. The special specifier @latest
triggers a crates.io lookup to install and run the newest published release if a newer one exists.
cargox
operates in a completely sandboxed environment, isolated from your
system's Cargo installation. This ensures that binaries installed by cargox
are
separate and don't interfere with your regular cargo install
workflow.
Default install locations:
- Linux/Unix:
~/.local/share/cargox/bin
(XDG Data Directory) - macOS:
~/Library/Application Support/cargox/bin
- Windows:
%APPDATA%\cargox\bin
Customizing the install directory:
You can override the default by setting:
CARGOX_INSTALL_DIR
: Custom location forcargox
installations
Complete sandboxing:
cargox
ensures complete isolation by:
-
Not checking standard Cargo directories: Binaries in
~/.cargo/bin
,~/.local/bin
,/usr/local/bin
, orCARGO_HOME/bin
are ignored when looking for already-installed binaries. -
Binary lookup is restricted to:
- Binaries already on your
PATH
(viawhich
) - The
cargox
install directory only
- Binaries already on your
-
Environment isolation: When installing packages,
cargox
removes all Cargo-related environment variables (likeCARGO_INSTALL_ROOT
,CARGO_HOME
,BINSTALL_INSTALL_PATH
, etc.) to prevent any leakage into the installation process. Only the controlledcargox
install directory is set.
This sandboxing guarantees that:
- You can test different versions without affecting your system installations
cargox
binaries won't accidentally shadow your regular Cargo binaries- The installation process is predictable and reproducible
Build artifact cleanup:
cargox
automatically cleans up build artifacts after installation:
- When using
cargo-binstall
, binaries are downloaded pre-built (no artifacts to clean) - When using
cargo install
, build artifacts are placed in a temporary directory that is automatically cleaned up after installation completes
This keeps your system clean and prevents build cache bloat.