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.
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 will remove an environment variable from the current process:
In PowerShell, you'll need to use [NullString]::Value
[1] rather than ""
or $null
when calling this API directly in order to remove an environment variable; e.g.:
# In v7.5+, only [NullString]::Value actually *removes* the variable.
[Environment]::SetEnvironmentVariable('HTTP_PROXY', [NullString]::Value)
''
(the empty string), you'll now get the following behavior:
Process
scope, i.e. for in-process environment variables, the variable will be created with (or set to) to the empty string.User
or Machine
scopes (supported on Windows only), a registry value that defines the variable with an empty string value technically is created, but such a value has no effect and is tantamount to removal of the variable; the reason is that when Windows instantiates a process' environment based on the persisted definitions in the registry, it ignores those whose value is the empty string.As per the decision published here, v7.5+ will surface this breaking change PowerShell-natively too; that is:
Only assigning $null
, i.e. $env:HTTP_PROXY = $null
in the case at hand, will result in an environment variable's removal going forward.
$env:HTTP_PROXY = ''
will define this variable as / set it to the empty string rather than removing it.
$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.
[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.)
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.
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 parameter.