If you saved a Windows environment variable but an already-open terminal cannot see it, first compare the variable’s scopes. A PowerShell session has its own process environment, inherited when it starts. Changing a saved User or Machine value does not automatically replace that existing process snapshot. Repeatedly saving the variable, running as administrator or rewriting PATH can therefore treat the wrong problem.
Understand the three Windows scopes
Microsoft’s environment-variable documentation distinguishes Process, User and Machine scopes. Process is the environment available to the current session. User and Machine values are persistent Windows settings used when environments are constructed. A child process normally inherits its parent’s environment, which explains why an editor’s integrated terminal may retain an older value.
An assignment such as $env:APP_MODE = 'test' changes the current process environment. It does not permanently save a User setting, nor does it update unrelated applications that are already running. Conversely, saving a User setting does not mean that the current PowerShell session has been refreshed.
Compare one variable without exposing everything
Open PowerShell and replace APP_MODE with the name you are investigating. These commands read values; they do not alter the saved configuration. Do not paste results into tickets if the variable contains a password, access token or another secret.
$name = 'APP_MODE'
[pscustomobject]@{
Process = [Environment]::GetEnvironmentVariable($name, 'Process')
User = [Environment]::GetEnvironmentVariable($name, 'User')
Machine = [Environment]::GetEnvironmentVariable($name, 'Machine')
}If User shows the intended value while Process shows an older value, that is evidence of a scope or inheritance mismatch, not proof that saving failed. If all three are absent, check the spelling, which Windows account saved the setting, and whether the application actually expects that name. An application can also have its own configuration system that takes precedence over environment variables.
A Machine value affects a broader audience and can require additional permissions to change. Do not copy a User value into Machine scope just to make one terminal work. First identify the scope the application is designed to use.
Use a harmless process-only experiment
Practice with a disposable variable rather than PATH, TEMP or a real application’s setting. This example preserves an existing nonempty value and restores it afterward. The chosen temporary value is deliberately nonempty to avoid differences in empty-string handling between PowerShell versions.
$name = 'WN_ENV_SCOPE_DEMO'
$before = [Environment]::GetEnvironmentVariable($name, 'Process')
try {
[Environment]::SetEnvironmentVariable(
$name, 'session-only-demo', 'Process'
)
[Environment]::GetEnvironmentVariable($name, 'Process')
[Environment]::GetEnvironmentVariable($name, 'User')
} finally {
if ($null -eq $before) {
Remove-Item -LiteralPath ('Env:' + $name) -ErrorAction SilentlyContinue
} else {
[Environment]::SetEnvironmentVariable($name, $before, 'Process')
}
}Use a different disposable name if this variable already exists with an empty value; the exercise intentionally avoids version-specific empty-value restoration. The Process read should show the temporary value, while the User read is unaffected. Nothing in this example persists a new system setting. If you deliberately stop the session, its process-only environment disappears with it.
Restart the application that owns the old environment
Save work before closing anything. After confirming that the persistent value is correct, fully exit the affected terminal application or editor, then reopen it from an appropriate Windows launcher. Creating another integrated terminal inside an old editor can still inherit the editor’s stale environment. Similarly, a new tab is not reliable evidence that every parent process has restarted.
Re-run the three-scope comparison in the new session before launching your application. If the new process still differs, inspect the launch chain, PowerShell profiles and application startup scripts for assignments that replace the value. For services or scheduled tasks, inspect their actual account and launch configuration instead of assuming your interactive user’s environment applies. Restarting production services needs a separate approved change plan.
If the symptom is specifically that a command cannot be found, environment inheritance is only one possibility. Continue with Get-Command and the difference between where and where.exe before editing command search paths.
Checklist before making a persistent change
- Identify the exact variable and expected Windows account.
- Compare Process, User and Machine values without dumping all secrets.
- Record the existing value and intended rollback before any approved edit.
- Test with a disposable process-only variable.
- Restart the relevant parent application, then inspect the new process.
- Investigate profiles and application overrides if the mismatch persists.
Do I need an administrator terminal? Not to read these example values or change a variable only in your own process. Elevation is not a substitute for checking scope. Should I reset PATH? No. A single missing custom variable does not justify a broad PATH rewrite, which can break unrelated tools.
Safety notice: This tutorial is for educational purposes. Test carefully before applying changes in production. The site owner is not responsible for misuse, damage, data loss or production issues.
