Search code examples
powershell

Cannot remove PowerShell environment variables

I set two environment variables HTTP_PROXY and HTTPS_PROXY in Windows PowerShell before. Now I want to remove them but I find that no matter how I type the command, the next time I open PowerShell, these two variables will appear again.

Here are the commands I have tried:

$env:HTTP_PROXY=''
$env:HTTPS_PROXY=''

[Environment]::SetEnvironmentVariable('HTTP_PROXY', '', 'User')
[Environment]::SetEnvironmentVariable('HTTPS_PROXY', '', 'User')
[Environment]::SetEnvironmentVariable('HTTP_PROXY', '', 'Machine')
[Environment]::SetEnvironmentVariable('HTTPS_PROXY', '', 'Machine')

Set-Location Env:
rm HTTP_PROXY
rm HTTPS_PROXY

But none of them works.

Solution

  • Update:

    • The solutions below work in Windows PowerShell and PowerShell (Core) 7 up to v7.4.x

    • PowerShell v7.5+ will be based on .NET 9+, which introduces a breaking change where only passing a null as the value to the [Environment]::SetEnvironmentVariable() overload that makes in-process changes[2] will remove an environment variable from the current process, whereas "" (the empty string) will define / keep the variable with that value (i.e. create an empty environment variable). The upshot is:

      • You'll need to use [NullString]::Value[1] rather than "" or $null when calling this API directly in order to remove a process-level variable; e.g.:

        # In v7.5+, only [NullString]::Value actually *removes* the variable.
[Environment]::SetEnvironmentVariable('HTTP_PROXY', [NullString]::Value)

      • It remains to be seen if and how PowerShell will surface this breaking change in v7.5+; that is, whether it will analogously allow e.g. $env:HTTP_PROXY = '' to define this variable as / set it to the empty string rather than removing it, and limit removal to assigning $null.

        • See GitHub issue #21186.

        • If the breaking change is surfaced, you'll need to use e.g., $env:HTTP_PROXY = $null for removal, going forward.

    In-process removal:

    $env:HTTP_PROXY=''
    $env:HTTPS_PROXY=''
    [Alternatively (though it's simpler to use e.g., rm env:HTTP_PROXY):]
    Set-Location Env:
    rm HTTP_PROXY
    rm HTTPS_PROXY

    The statements above remove the specified environment variables from the current session (process) only.

    Note:

    • On Unix-like platforms you'd have to use alias ri instead of rm, or use the cmdlet's full name, Remove-Item, instead; e.g., without using Set-Location first, ri Env:HTTP_PROXY.

    • See also: about_Environment_Variables.

    However, if these environment variables are defined persistently, via the registry (on Windows), they will resurface in future sessions.

    Persistent removal (Windows only):

    [Environment]::SetEnvironmentVariable('HTTP_PROXY', '', 'User')
    [Environment]::SetEnvironmentVariable('HTTPS_PROXY', '', 'User')
    [Environment]::SetEnvironmentVariable('HTTP_PROXY', '', 'Machine')
    [Environment]::SetEnvironmentVariable('HTTPS_PROXY', '', 'Machine')

    The statements above - assuming they execute without triggering an exception - do remove the persistent definitions (on Windows only).

    • Note that setting / removing machine-level variables ('Machine') requires elevation (running as admin).

    • [See update at the top] By design, any of the following values causes the specified environment variable to be deleted: '', [NullString]::Value (the equivalent of null in C#[1]), "`0" (a single NUL (0x0) char.)

      • As an aside: This permissiveness is problematic, as it prevents creating environment variables whose value is the empty string, which is not uncommon on Unix-like platforms - see GitHub issue #50554.

    • Note that these methods remove only the persistent definitions of these variables - any definitions in the current session (process) are left untouched; to also remove them, use the methods at the top.

    If the environment variables unexpectedly still resurface in future sessions, there are two potential causes:

    • Perhaps you started a new session directly from the old session, e.g. with Start-Process powershell.exe - in that case the current session's environment variables are inherited by the new session, so unless you've removed the environment variable from the current session as well, the new session will see them.

    • There may be code in your profile files, notably $PROFILE, that (re)defines these environment variables whenever a new session starts.

      • To rule out this possibility, use the Windows Run dialog (WinKey-R) and submit powershell -noprofile, then check if these variables are still present.

    [1] PowerShell does have a $null constant that is generally the equivalent of C#'s null, but in a string context PowerShell forces $null values to '' (the empty string). Therefore, the [NullString]::Value singleton is required in order to pass a genuine null value to a string-typed .NET method.

    [2] The API overload that makes persistent changes is (a) fundamentally only supported on Windows and (b) you cannot persist empty environment variables there.