About this article
This article was created using an automated generation workflow powered by generative AI. It reviews the concepts of the .NET Environment API and Windows environment variables, walking through a procedure to observe the differences between Process and User scopes using only dummy variables that do not break existing values.
Verification Status: 📘 Official information confirmed, Windows physical machine not verified
It is not surprising that a value set in PowerShell with $env:PAPANDA_DEMO = 'A' disappears in a newly opened PowerShell instance. Environment variables limited to the current Process and those saved as User or Machine have different scopes.
We will examine this difference by modifying it in the console and verifying the results in the Windows environment variable GUI.
Check before making changes
First, use only a dummy name.PATH Do not change existing API keys.
$name = 'PAPANDA_DEMO'
[pscustomobject]@{
Process = [Environment]::GetEnvironmentVariable($name, 'Process')
User = [Environment]::GetEnvironmentVariable($name, 'User')
Machine = [Environment]::GetEnvironmentVariable($name, 'Machine')
}
The .NET Environment API allows reading and writing by specifying the target.
Modify only the Process scope first
$env:PAPANDA_DEMO = 'process-only' Write-Host "[RESULT] current process = $env:PAPANDA_DEMO"
Even if you open the Windows "Environment Variables" GUI in this state, PAPANDA_DEMO will not normally appear in the user environment variables list because it was set only for the current PowerShell process.
flowchart LR
P[現在のPowerShell Process] -->|$env:で設定| PE[Process environment]
U[User environment] --> N[新しく起動するProcess]
M[Machine environment] --> N
PE -. 現在のProcessだけ .-> P
Set a value in the User scope only
Next, set a dummy value in the User scope. We will not touch Machine scope during this experiment due to administrator privilege requirements and its wider impact.
[Environment]::SetEnvironmentVariable(
'PAPANDA_DEMO',
'user-value',
'User'
)
Write-Host '[SUCCESS] User scopeへPAPANDA_DEMOを設定しました'
Verification using the GUI
On Windows 11, open "Environment Variables" from "Advanced system settings", and check if User environment variables contains PAPANDA_DEMO = user-value.
What this shows is not that "PowerShell and the GUI have separate settings", but rather thatyou are viewing the same User scope settings through different entry points.
Verify again in the console
[Environment]::GetEnvironmentVariable('PAPANDA_DEMO', 'User')
user-valueIf
is returned, the observation results from the GUI and the console match. As a note of caution, the $env:PAPANDA_DEMO of an already running process is not guaranteed to automatically update to the User value. Be mindful of the timing differences regarding when new processes inherit their environment.
Change a single location
Change only the User value from user-value to user-value-2, reopen the GUI, and verify if the displayed value changes.
[Environment]::SetEnvironmentVariable(
'PAPANDA_DEMO',
'user-value-2',
'User'
)
Revert to original state
Once testing is complete, delete the dummy variable from the User scope.
[Environment]::SetEnvironmentVariable(
'PAPANDA_DEMO',
$null,
'User'
)
Remove-Item Env:PAPANDA_DEMO -ErrorAction SilentlyContinue
Write-Host '[CLEANUP] PAPANDA_DEMOを削除しました'
Confirm that it has also disappeared from the GUI.
For professional use
While environment variables are convenient, they are not a universal solution for storing secret information.
Distinguish between the impact ranges of Process, User, and Machine scopes
Do not modify the Machine PATH by copy-pasting from tutorials
Do not display actual API keys on screens or in logs
Services may run in a different environment from the interactive user
Do not scatter setting sources across multiple locations
Deciding "where things are configured" is crucial for operations.
Official and Primary Sources
Summary
Although Process, User, and Machine are all "environment variables," their lifespans and impact scopes differ. By setting a dummy variable in the User scope, verifying it in both the GUI and PowerShell, and then deleting it, you can safely experience how Windows settings are simply viewed through different entry points.
