Help test Windows behavior between rustup and cargo

We're looking for help with testing a fix with how rustup behaves on Windows. If you are on Windows, you can help by setting the environment variable RUSTUP_WINDOWS_PATH_ADD_BIN to 0. There are a variety of ways to set an environment variable in Windows, but the easiest is probably to just search for "environment variable" in the start menu, Settings, or the Control Panel, and then click "Environment Variables..." and add it as a user variable. You will then need to restart your terminal, editor, or IDE to pick up the change.

If you experience any problems that seem to be introduced by this (such as cargo commands not behaving with toolchains correctly), please file an issue.

What does this change do?

Historically, rustup has modified the PATH environment variable on Windows when it runs cargo or other tools so that the toolchain's "sysroot" bin directory is added to the PATH (for example, C:\Users\eric\.rustup\toolchains\stable-x86_64-pc-windows-msvc\bin). This means that when a command like cargo needed to execute rustc, or recursively execute cargo like in a third-party subcommand, it would come directly from the toolchain's bin directory instead of using the rustup proxy (which is located in your cargo home, such as C:\Users\eric\.cargo\bin).

Setting RUSTUP_WINDOWS_PATH_ADD_BIN=0 will change rustup to avoid changing the PATH variable so that cargo subcommands will execute the rustup proxies instead of directly from the toolchain directory.

Modifying PATH was originally done for various reasons that are complicated and not really relevant anymore. However, out of an abundance of caution, we are asking people to test the change before we enable it by default for everyone just in case there are any issues that we have not foreseen. For example, there might be some subtle issues with loading the rustc or std DLLs.

This change was also delayed because previously it would cause cargo to run rustc through the rustup wrapper, which would have incurred a significant overhead. That has been resolved as of Rust 1.71 (via cargo#11917) which changed cargo to avoid the wrapper automatically.

This change does not affect any other platforms because they already do not modify PATH. Setting RUSTUP_WINDOWS_PATH_ADD_BIN will have no effect on non-Windows platforms.

What does this fix?

Because rustup is placing the toolchain bin directory in PATH, that was preventing recursive calls to commands like cargo from to specifying or changing the current rustup toolchain. For example, if the subsequent commands do something like running cargo +nightly metadata, it would get an error like no such command: +nightly because it was trying to execute cargo directly instead of via the rustup proxy. Similarly setting the RUSTUP_TOOLCHAIN environment variable would also not work.

The following are examples that would fail if they try to run cargo or rustc with a different toolchain (like with the + shorthand or with the RUSTUP_TOOLCHAIN environment variable):

We appreciate your help, as we hope to switch the default in an upcoming release of rustup.


For proper testing, do we need to remove Rust from the PATH? Or remove Rust, set the environment variable, then reinstall Rust?

1 Like

I don't think you need to make any changes to your existing installation like changing PATH or reinstalling. The environment varable won't affect installing rustup itself.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.