cargo missing from PATH in vscode powershell

Question

I have just installed Rust and VS Code on a new windows machine.

I have confirmed that Rust was installed successfully and has been added to PATH

PS C:\Users\Steven> cargo --version
cargo 1.53.0 (4369396ce 2021-04-27)

PS C:\Users\Steven> $env:path -split ";"
C:\Windows\system32
C:\Windows
C:\Windows\System32\Wbem
C:\Windows\System32\WindowsPowerShell\v1.0\
C:\Windows\System32\OpenSSH\
C:\Users\Steven\.cargo\bin
C:\Users\Steven\AppData\Local\Microsoft\WindowsApps

C:\Users\Steven\AppData\Local\Programs\Microsoft VS Code\bin

But when I launch vscode and try to use cargo from the integrated terminal, it is missing. The PATH for the integrated powershell terminal in VS Code is also different.

PS C:\Users\Steven> cargo --version
cargo : The term 'cargo' is not recognized as the name of a cmdlet, function, script file, or operable program.

PS C:\Users\Steven> $env:path -split ";" 
C:\Program Files\Mozilla Firefox
C:\Windows\system32
C:\Windows
C:\Windows\System32\Wbem
C:\Windows\System32\WindowsPowerShell\v1.0\
C:\Windows\System32\OpenSSH\
C:\Users\Steven\AppData\Local\Microsoft\WindowsApps

Why is the PATH in VSCode's ppowershell different?

How can I use cargo from within VSCode's integrated terminal?

Answer 1

If you just installed Rust, you may need to log off from Windows and log back in in order for changes to environment variables to be applied correctly.

Every process has its own set of environment variables. Usually, environment variables are inherited from their parent process. When you installed Rust, rustup configured your user-level environment variables in the Windows Registry, but that doesn't refresh the environment of already-running processes.

There are some ways in which Windows Explorer/File Explorer will reload the system/user environment variables before spawning processes and some ways in which it won't. Most other programs don't even bother. It's easier to just log off and start from a clean slate.

The same is true on other operating systems as well (though system/user environment variables are stored in login scripts, not in the Registry, obviously).