Rust cargo Subcommand Missing After a Toolchain Switch in CI
A cargo subcommand that worked earlier in the job stops being found after a rustup channel switch or a cargo +toolchain invocation. The plugin binary lives in ~/.cargo/bin (or is toolchain-scoped), and the new toolchain context isn’t seeing it.
What this error means
A cargo nextest/cargo llvm-cov/cargo deny step fails with no such command only after the job changed toolchains (e.g. ran a nightly step, or rustup default changed). The same command worked before the switch.
# step 1 (stable): cargo nextest run -> works
# step 2: rustup default nightly
# step 3: cargo nextest run
error: no such command: `nextest`
View all installed commands with `cargo --list`Common causes
PATH/toolchain context changed
A cargo +toolchain run or a rustup default switch changes which cargo is invoked and what’s on PATH. If the plugin isn’t visible in the new context, the subcommand isn’t found.
Plugin installed against a different toolchain
Some setups install plugins per-toolchain. After switching channels, a plugin built for the previous toolchain may not be picked up by the new one.
How to fix it
Ensure ~/.cargo/bin is on PATH for every step
Most cargo plugins install to ~/.cargo/bin, which is toolchain-independent. Keep it on PATH so the subcommand survives channel switches.
echo "$HOME/.cargo/bin" >> "$GITHUB_PATH"
cargo --list # confirm the plugin shows upInstall plugins via a pinned-binary action
Prebuilt-binary installers drop a standalone binary on PATH that doesn’t depend on the active toolchain.
- uses: taiki-e/install-action@v2
with:
tool: cargo-nextest,cargo-llvm-covHow to prevent it
- Keep
~/.cargo/binon PATH across all job steps. - Install cargo plugins as standalone binaries (taiki-e/install-action).
- Avoid switching the default toolchain mid-job; scope nightly to specific steps.