`install_if_missing`/`should_auto_install` is being asked too eagerly when `RUSTUP_AUTO_INSTALL=1`

[rami3l]

Verification

• I searched for recent similar issues at https://github.com/rust-lang/rustup/issues?q=is%3Aissue and found no duplicates.
• I am on the latest version of Rustup according to https://github.com/rust-lang/rustup/tags and am still able to reproduce my issue.

Problem

Prerequisite for #4454.

When resolving to a toolchain, if RUSTUP_AUTO_INSTALL is enabled, rustup will try to resolve the toolchain no matter what, and this will cause the toolchain to be installed.

For example, even rustup +beta target remove aarch64-apple-darwin will cause beta to be installed when it is not installed yet.

Steps

As noticed in #4454 (comment), this behavior dates even before v1.27.1:

> docker run --rm -it rust:alpine sh

> rustup --version
rustup 1.27.1 (54dd3d00f 2024-04-24)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.81.0 (eeb90cda1 2024-09-04)`

> rustup +beta target remove aarch64-apple-darwin
info: syncing channel updates for 'beta-aarch64-unknown-linux-musl'
1007.6 KiB / 1007.6 KiB (100 %) 567.4 KiB/s in  1s ETA:  0s
info: latest update on 2025-09-28, rust version 1.91.0-beta.4 (aa7859c0d 2025-09-27)
info: downloading component 'cargo'
^C

Possible Solution(s)

In the future, it might be reasonable to restrict auto installation behavior to a reasonable subset, even with RUSTUP_AUTO_INSTALL set to 1.

Thus, the suggested solution here would be to perform a case-by-case analysis to restrict auto install behavior, and hopefully eventually to the strict minimum.

For example, as the first step, for rustup component it might be reasonable to ban auto installation altogether; or we can even ban all cases in rustup_mode.rs, etc. It really depends on in what way v1.28.0 was broken for our users.

Notes

Also related to #4211.

Implicit behaviors like this is one of the very important justifications for not shipping RUSTUP_AUTO_INSTALL=1; the test failures in #4454 has also demonstrated how often this setting is consulted which might be surprising even for those who use/support auto installation.

Rustup version

> rustup --version
rustup 1.30.0 :: 1.28.2+599 (4fed1c800 2026-04-26)

Installed toolchains

N/A

OS version

macOS 26.4.1 (25E253)

[ChrisDenton]

Yes, I do think the set of commands that could trigger auto install should be minimal.

[djc]

The command you used as an example is clearly nonsensical but it feels nonsensical mostly because it's not actually invoking any rustc command. So maybe the problem here is accepting a +toolchain for arbitrary commands in general, more than it is about auto-installing the toolchain?

[rami3l]

The command you used as an example is clearly nonsensical but it feels nonsensical mostly because it's not actually invoking any rustc command. So maybe the problem here is accepting a +toolchain for arbitrary commands in general, more than it is about auto-installing the toolchain?

@djc I see your point but that's not true, because +toolchain being one of the global override methods, the same will apply if we enforce the toolchain via an environment variable, or even using rust-toolchain.toml.

In other words, auto-installation means "when the active toolchain is not installed, rustup will try to install it first before proceeding". This has relatively weak connection to how the active toolchain is determined in the first place.